Commit 3a9ed298 authored by Andrew Morton's avatar Andrew Morton Committed by Linus Torvalds

[PATCH] misc (mainly documentation)

- hugetlb Documentation update

- Add /proc/buddyinfo documentation

- nano-cleanup in __remove_from_page_cache.
parent 7570df54
......@@ -191,6 +191,7 @@ Table 1-3: Kernel info in /proc
..............................................................................
File Content
apm Advanced power management info
buddyinfo Kernel memory allocator information (see text) (2.5)
bus Directory containing bus specific information
cmdline Kernel command line
cpuinfo Info about the CPU
......@@ -275,7 +276,7 @@ output of a SMP machine):
ERR: 2155
NMI is incremented in this case because every timer interrupt generates a NMI
(Non Maskable Interrupt) which is used by the NMI Watchdog to detect lookups.
(Non Maskable Interrupt) which is used by the NMI Watchdog to detect lockups.
LOC is the local interrupt counter of the internal APIC of every CPU.
......@@ -326,6 +327,25 @@ Linux uses slab pools for memory management above page level in version 2.2.
Commonly used objects have their own slab pool (such as network buffers,
directory cache, and so on).
..............................................................................
> cat /proc/buddyinfo
Node 0, zone DMA 0 4 5 4 4 3 ...
Node 0, zone Normal 1 0 0 1 101 8 ...
Node 0, zone HighMem 2 0 0 1 1 0 ...
Memory fragmentation is a problem under some workloads, and buddyinfo is a
useful tool for helping diagnose these problems. Buddyinfo will give you a
clue as to how big an area you can safely allocate, or why a previous
allocation failed.
Each column represents the number of pages of a certain order which are
available. In this case, there are 0 chunks of 2^0*PAGE_SIZE available in
ZONE_DMA, 4 chunks of 2^1*PAGE_SIZE in ZONE_DMA, 101 chunks of 2^4*PAGE_SIZE
availble in ZONE_NORMAL, etc...
1.3 IDE devices in /proc/ide
----------------------------
......
......@@ -25,13 +25,13 @@ key: If a user application wants to share hugepages with other
memory (mapped by hugeTLBs) in their address space. When a process
forks, then children share the same physical memory with their parent.
For the cases when an application wishes to keep the huge pages
private, the key value of 0 is defined. In this case kernel allocates
hugetlb pages to the process that are not shareable across different
processes. These segments are marked private for the process. These
segments are not copied to children's address space on forks.
AKPM: So what is present at that address within the child?
For the cases when an application wishes to keep the huge
pages private, the key value of 0 is defined. In this case
kernel allocates hugetlb pages to the process that are not
shareable across different processes. These segments are marked
private for the process. These segments are not copied to
children's address space on forks - the child will have no
mapping for these virtual addresses.
The key manangement (and assignment) part is left to user
applications.
......
......@@ -73,10 +73,9 @@ void __remove_from_page_cache(struct page *page)
{
struct address_space *mapping = page->mapping;
if (unlikely(PageDirty(page)) && !PageSwapCache(page))
BUG();
BUG_ON(PageDirty(page) && !PageSwapCache(page));
radix_tree_delete(&page->mapping->page_tree, page->index);
radix_tree_delete(&mapping->page_tree, page->index);
list_del(&page->list);
page->mapping = NULL;
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment