Linux kernel memory-faq.txt
## Linux kernel memory-faq.txt
What is some existing documentation on Linux memory management?
Ulrich Drepper (the ex-glibc maintainer) wrote an article series called
"What every programmer should know about memory":
Part 1: http://lwn.net/Articles/250967/
Part 2: http://lwn.net/Articles/252125/
Part 3: http://lwn.net/Articles/253361/
Part 4: http://lwn.net/Articles/254445/
Part 5: http://lwn.net/Articles/255364/
Part 6: http://lwn.net/Articles/256433/
Part 7: http://lwn.net/Articles/257209/
Part 8: http://lwn.net/Articles/258154/
Part 9: http://lwn.net/Articles/258188/
Mel Gorman's book "Understanding the Linux Virtual Memory Manager" is
available online:
http://kernel.org/doc/gorman/
What is virtual memory?
Virtual memory provides a software-controlled set of memory addresses,
allowing each process to have its own unique view of a computer's memory.
Virtual addresses only make sense within a given context, such as a
specific process. The same virtual address can simultaneously mean
different things in different contexts.
Virtual addresses are the size of a CPU register. On 32 bit systems each
process has 4 gigabytes of virtual address space all to itself, which is
often more memory than the system actually has.
Virtual addresses are interpreted by a processor's Memory Management Unit
(mmu), using data structures called page tables which map virtual address
ranges to associated content.
Virtual memory is used to implement lazy allocation, swapping, file mapping,
copy on write shared memory, defragmentation, and more.
For details, see Ulrich Drepper's "What every programmer should know
about memory, Part 3: Virtual Memory":
http://lwn.net/Articles/253361/
What is physical memory?
Physical memory is storage hardware that records data with low latency and
small granularity. Physical memory addresses are numbers sent across a
memory bus to identify the specific memory cell within a piece of
storage hardware associated with a given read or write operation.
Examples of storage hardware providing physical memory are DIMMs (DRAM),
SD memory cards (flash), video cards (frame buffers and texture memory),
network cards (I/O buffers), and so on.
Only the kernel uses physical memory addresses directly. Userspace
programs exclusively use virtual addresses.
For details, see the ARS Technica DRAM Guide:
http://arstechnica.com/paedia/r/ram_guide/ram_guide.part1-1.html
http://arstechnica.com/paedia/r/ram_guide/ram_guide.part2-1.html
http://arstechnica.com/paedia/r/ram_guide/ram_guide.part3-1.html
And Ulrich Drepper's "What every programmer should know about memory,
Part 1":
http://lwn.net/Articles/250967/
What is a Memory Management Unit (MMU)?
The memory management unit is the part of the CPU that interprets virtual
addresses. Attempts to read, write, or execute memory at virtual addresses
are either translated to corresponding physical addresses, or else
generate an interrupt (page fault) to allow software to respond to the
attempted access.
This gives each process its own virtual memory address range, which is
limited only by address space (4 gigabytes on most 32-bit system), while
physical memory is limited by the amount of available storage hardware.
Physical memory addresses are unique in the system, virtual memory addresses
are unique per-process.
What are page tables?
Page tables are data structures which containing a process's list of memory
mappings and track associated resources. Each process has its own
set of page tables, and the kernel also has a few page table entries for
things like disk cache.
32-bit Linux systems use three-level tree structures to record page tables.
The levels are the Page Upper Directory (PUD), Page Middle Directory (PMD),
and Page Table Entry (PTE). (64-bit Linux can use 4-level page tables.)
For details, see:
http://en.wikipedia.org/wiki/Page_table
What are memory mappings?
A memory mapping is a set of page table entries describing the properties
of a consecutive virtual address range. Each memory mapping has a
start address and length, permissions (such as whether the program can
read, write, or execute from that memory), and associated resources (such
as physical pages, swap pages, file contents, and so on).
Creating new memory mappings allocates virtual memory, but not physical
memory (except for a small amount of physical memory needed to store the
page table itself). Physical pages are attached to memory mappings later,
in response to page faults. Physical memory is allocated on-demand by the
page fault handler as necessary to resolve page faults.
A page table can be thought of as a description of a set of memory
mappings. Each memory mapping can be anonymous, file backed, device backed,
shared, or copy on write.
The mmap() system call adds a new memory mapping to the current process's
page tables. The munmap() system call discards an existing mapping.
Memory mappings cannot overlap. The mmap() call returns an error if asked
to create overlapping memory mappings.
Virtual address ranges for which there is no current memory mapping are said
to be "unmapped", and attempts to access them generate a page fault which
cannot be handled. The page fault handler sends a Segmentation
Violation signal (SIGSEGV) to the program on any access to unmapped
addresses. This is generally the result of following a "wild pointer".
Note that by default, Linux intentionally leaves the first few kilobytes
(or even megabytes) of each process's virtual address space unmapped, so
that attempts to dereference null pointers generate an unhandled page
fault resulting in an immediate SIGSEGV, killing the process.
For details, see the Single Unix Specification version 4 entry for the
mmap() system call:
http://www.opengroup.org/onlinepubs/9699919799/functions/mmap.html
And the glibc mmap() documentation:
http://www.gnu.org/s/libc/manual/html_node/Memory_002dmapped-I_002fO.html
What are shared pages?
Multiple Page Table Entries can map the same physical page. Access through
these virtual addresses (often in different processes) all show the same
contents, and changes to it are immediately visible to all users. (Shared
writable mappings are a common high-performance inter-process communication
mechanism.)
The number of PTEs mapping each physical page is tracked, and when the
reference count falls to zero the page is moved to the free memory list.
What is an anonymous mapping?
Anonymous memory is a memory mapping with no file or device backing it.
This is how programs allocate memory from the operating system for use
by things like the stack and heap.
Initially, an anonymous mapping only allocates virtual memory. The new
mapping starts with a redundant copy on write mapping of the zero page.
(The zero page is a single page of physical memory filled with zeroes,
maintained by the operating system.) Every virtual page of the anonymous
mapping is attached to this existing prezeroed page, so attempts to read
from anywhere in the mapping return zeroed memory even though no new
physical memory has been allocated to it yet.
Attempts to write to the page trigger the normal copy-on-write mechanism in
the page fault handler, allocating fresh memory only when needed to allow
the write to proceed. (Note, prezeroing optimizations change the
implementation details here, but the theory's the same.) Thus "dirtying"
anonymous pages allocates physical memory, the actual allocation call only
allocates virtual memory.
Dirty anonymous pages can be written to swap space, but in the absence of
swap they remain "pinned" in physical memory.
Anonymous mappings may be created by passing the MAP_ANONYMOUS flag to
mmap().
What is a file backed mapping?
File backed mappings mirror the contents of an existing file. The mapping
has some administrative data noting which file to map from, and at which
offset, as well as permission bits indicating whether the pages may be read,
written, or executed.
When page faults attach new physical pages to such a mapping, the contents of
those pages is initialized by reading the contents of the file being mapped,
at the appropriate offset for that page.
These physical pages are usually shared with the page cache, the kernel's
disk cache of file contents. The kernel caches the contents of files
when the page is read, so sharing those cache pages with the process reduces
the total number of physical pages required by the system.
Writes to file mappings created with the MAP_SHARED flag update the page
cache pages, making the updated file contents immediately visible to other
processes using the file, and eventually the cache pages will be flushed
to disk updating the on-disk copy of the file.
Writes to file mappings created with the MAP_PRIVATE flag perform a
copy on write, allocating a new local copy of the page to store the
changes. These changes are not made visible to other processes, and do
not update the on-disk copy of the file.
Note that this means writes to MAP_SHARED pages do not allocate additonal
physical pages (the page was already faulted into the page cache by the
read, and the data can be flushed back to the file if the physical page
is needed elsewhere), but writes to MAP_PRIVATE pages do (the copy in
the page cache and the local copy the program needs diverge, so two pages
are needed to store them, and flushing the page cache copy back to disk
won't free up the local copy of the changed contents).
What is the page cache?
The page cache is the kernel' cache of file contents. It's the main
user of virtual memory that doesn't belong to a specific process.
See "What is a file backed mapping" and "What is free memory" for more info.
What is CPU cache?
The CPU cache is a very small amount of very fast memory built into a
processor, containing temporary copies of data to reduce processing latency.
The L1 cache is a tiny amount of memory (generally between 1k and 64k)
wired directly into the processor that can be accessed in a single clock
cycle. The L2 cache is a larger amount of memory (up to several
megabytes) adjacent to the processor, which can be accessed in a small
number of clock cycles. Access to uncached memory (across the memory bus)
can take dozens, hundreds, or even thousands of clock cycles.
(Note that latency is the issue CPU cache addresses, not throughput. The
memory bus can provide a constant stream of memory, but takes a while to
start doing so.)
For details, see Ulrich Drepper's "What every programmer should know
about memory, Part 2":
http://lwn.net/Articles/252125/
What is a Translation Lookaside Buffer (TLB)?
The TLB is a cache for the MMU. All memory in the CPU's L1 cache must
have an associated TLB entry, and invalidating a TLB entry flushes the
associated cache line(s).
The TLB is a small fixed-size array of recently used pages, which the
CPU checks on each memory access. It lists a few of the virtual address
ranges to which physical pages are currently assigned.
Accesses to virtual addresses listed in the TLB go directly through to the
associated physical memory (or cache pages) without generating page faults
(assuming the page permissions allow that category of access). Accesses
to virtual addresses not listed in the TLB (a "TLB miss") trigger a page
table lookup, which is performed either by hardware, or by the page fault
handler, depending on processor type.
For details, see:
http://en.wikipedia.org/wiki/Translation_lookaside_buffer
1995 interview with Linus Torvalds describing the i386, PPC, and Alpha TLBs:
http://www.linuxjournal.com/article/36
What is a page fault handler?
A page fault handler is an interrupt routine, called by the Memory
Management Unit in response an attempt to access virtual memory which
did not immediately succeed.
When a program attempts to read, write, or execute memory in a page that
hasn't got the appropriate permission bits set in its page table entry
to allow that type of access, the instruction generates an interrupt. This
calls the page fault handler to examines the registers and page tables of
the interrupted process and determine what action to take to handle
the fault.
The page fault handler may respond to a page fault in three ways:
1) The page fault handler can resolve the fault by immediately attaching a
page of physical memory to the appropriate page table entry, adjusting
the entry, and resuming the interrupted instruction. This is called a
"soft fault".
2) When the fault handler can't immediately resolve the fault, it may
suspend the interrupted process and switch to another while the system
works to resolve the issue. This is called a "hard fault", and results
when an I/O operation most be performed to prepare the physical page
needed to resolve the fault.
3) If the page fault handler can't resolve the fault, it sends a signal
(SIGSEGV) to the process, informing it of the failure. Although a process
can install a SIGSEGV handler (debuggers and emulators tend to do this),
the default behavior of an unhandled SIGSEGV is to kill the process with
the message "bus error".
A page fault that occurs in an interrupt handler is called a "double fault",
and usually panics the kernel. The double fault handler calls the kernel's
panic() function to print error messages to help diagnose the problem.
The process to be killed for accessing memory it shouldn't is the
kernel itself, and thus the system is too confused to continue.
http://en.wikipedia.org/wiki/Double_fault
A triple fault cannot be handled in software. If a page fault occurrs in
the double fault handler, the machine immediately reboots.
http://en.wikipedia.org/wiki/Triple_fault
How does the page fault handler allocate physical memory?
The Linux kernel uses lazy (on-demand) allocation of physical pages,
deferring the allocation until necessary and avoiding allocating physical
pages which will never actually be used.
Memory mappings generally start out with no physical pages attached. They
define virtual address ranges without any associated physical memory. So
malloc() and similar allocate space, but the actual memory is allocated
later by the page fault handler.
Virtual pages with no associated physical page will have the read,
write, and execute bits disabled in their page table entries. This causes
any access to that address to generate a page fault, interrupting the
program and calling the page fault handler.
When the page fault handler needs to allocate physical memory to handle
a page fault, it zeroes a free physical page (or grabs a page from a pool
of prezeroed pages), attaches that page of memory to the Page Table Entry
associated with the fault, updates that PTE to allow the appropriate access,
and resumes the faulting instruction.
Note that implementing this requires two sets of page table flags for
read, write, execute, and share. The VM_READ, VM_WRITE, VM_EXEC, and
VM_SHARED flags (in linux/mm.h) are used by the MMU to generate faults.
The VM_MAYREAD, VM_MAYWRITE, VM_MAYEXEC, and VM_MAYSHARE flags are used by
the page fault handler to determine whether the attempted access was legal
and thus the fault handler should adjust the PTE to resolve the fault and
allow the process to continue.
How does fork work?
The fork() system call creates a new process by copying an existing
process. A new process is created with a copy of the page tables
that calls fork(). These page tables are all copy on write mappings
sharing the existing physical pages between parent and child.
How does exec work?
The exec() system call executes a new file in the current process
context. It blanks the process's current page table, discarding all
existing mappings, and replaces them with a fresh page table containing
a small number of new mappings, including an executable mmap() of the new
file passed to the exec() call, a small amount of administrative space
containing the environment variables and command line arguments passed
into the new program, a new process stack, and so on.
The normal way to launch a new process in Unix-like systems is to call
fork(), followed immediately by a call to exec() in the new process.
Thus fork() copies the parent process's existing process's memory mappings
into the new process, then exec() immediately discards them again.
Because these were shared mappings, the fork() allocates a lot of virtual
space but consumes very few new physical pages.
How do shared libraries work?
Only statically linked executables are executed directly. Shared libraries
are executed by the dynamic linker (either ld-linux.so.2 or ld-uClibc.so.0),
which despite the name is a statically linked executable that works a bit
like #!/bin/sh or #!usr/bin/perl in shell scripts. It's the binary that's
launched to run this program, and the path to this program is fed to it as
its first argument.
The dynamic linker mmap()s the executable files, and any shared libraries
it needs, using the MAP_PRIVATE flag. This allows it to write to those
pages to perform the dynamic linking fixups allowing the executable's calls
out to the shared library code to connect. (It calls mprotect() to set the
pages read only before handing control over to the linked executable.)
The dynamic linker traces through various lists of calls in the program's
ELF tables, looks up the appropriate function pointer for each one, and
writes that pointer to the call site in the memory mapping.
Pages the dynamic linker writes to are essentially converted to anonymous
pages by breaking the copy-on-write. These new "dirtied" pages allocate
physical memory visible only to this process. Thus keeping to a minimum
the number of dirtied pages allows the rest to remain shared, and thus saves
memory.
Shared libraries are normally compiled with the -fpic flag (Position
Independent Code), which creates an object table containing all the
references to external calls to data and functions. Instead of reaching
out and touching the shared objects directly, the code bounces off this
table. This makes the code slightly larger by inserting an extra jump
or extra load, but the advantage is that all the external references
modified by the linker are grouped together into a small number of pages.
So the binary is slightly larger, but more of the pages are shared since
the number of physical pages dirtied by the dynamic linker is smaller each
time the shared object is used.
Normally only shared libraries are compiled this way, but some programs
(such as busybox) which the system expects to run many instances of may
also benefit from the increased sharing more than they suffer from the
increased size.
Note that statically linked programs have no fixups applied to them, and
thus no private executable pages. Every page of their executable mapping
remains shared. They also spawn faster, since there's no dynamic linker
performing fixups. Thus in some circumstances, static linking is actually
more efficient than dynamic linking. (Strange but true.)
How does copy on write work?
If two page table entries point to the same physical page, the contents
of that page show up in both locations when read. A reference counter
associated with the page tracks how many page table entries point to that
page. Each of those page table entries has read permission (but not
write permissions) for the page.
Attemps to write to the page generate a page fault. The page fault handler
allocates a new physical page, copies the contents of the shared page into
the new page, attaches the new page to the faulting page table entry, sets
the updated PTE writeable, decrements the count on the old shared page
(possibly removing its shared status if the reference count falls to 1),
and resumes the faulting process allowing the write to go through to the
new nonshared copy of the page.
This is a form of lazy allocation, deferring memory allocation until
the new memory is actually used.
What are clean pages?
Clean pages have copies of their data stored elsewhere, such as in swap
space or in a file. Thus the physical memory storing that information may
be reclaimed an reused elsewhere by detaching the physical page from the
associated Page Table Entry. When the page's contents are needed again,
a new physical page may be allocated and its contents read from the stored
copy.
What are active pages?
Active pages are page table entries that have associated physical pages
which have been used recently.
The system can track active pages by removing the read, write, and execute
bits from page table entries but leaving the associated physical page
still attached, then taking a soft fault the next time that page is
accessed. The fault handler can cheaply switch the appropriate access
bit back on and resume the faulting instruction, thereby recording that
the page is currently in use.
Pages which are active are poor candidates for page stealing, even if
they are clean, because the process using them will quickly fault a new
physical page back in again if the current one is reclaimed.
Note that reading a lot of filesystem data marks cache pages as active,
since they're recently used. This not only causes the page cache to
allocate lots of physical pages, but prevents those pages from being
reclaimed since they were used more recently than other pages in the
system.
What are free pages?
When a page's reference count goes to zero, the page is added to the free
list inside the kernel. These free pages are not currently used for any
purpose, and are essentially wasted until some use is found for them.
A freshly booted system starts with lots of free pages. Free pages also
occur when processes exit(), or when munmap() discards a mapping and the
private pages associated with it.
The kernel tries to minimize the number of free pages in the system.
Instead, it tries to find uses for these pages which improve performance of
existing processes, but which leaves them easily reclaimable if the memory
is needed for another purpose.
For example, the page cache keeps around copies of file contents long
after they were last accessed, potentially avoiding an expensive disk
access if that file is read again in future. If those pages are needed
for other purposes, the cached contents can easily be discarded and the
pages reallocated.
What is page stealing?
Page stealing is a response to a shortage of free pages, by "stealing"
existing allocated physical pages from their current users. It's a
statistical method of effectively obtaining extra physical pages by
identifying existing allocations unlikely to be used again in the
near future and recycling them.
Page stealing removes existing physical pages from their mappings, disposes
of their current contents (often by writing them to disk), and reuses the
memory elsewhere. If the original user needs their page back, a new
physical page is allocated and the old contents loaded into the new page.
Page stealing looks for inactive pages, since active ones would probably
just be faulted back in again immediately. Clean inactive pages are almost
as good as free pages, because their current contents are already copied
somewhere else and can be discarded without even performing any I/O.
Dirty pages are cleaned by scheduling I/O to write them to backing store
(swap for anonymous pages, to the mapped file for shared file backed
mappings).
Page stealing attempts to determine which existing physical pages are least
likely to be needed again soon, meaning its trying to predict the future
actions of the processes using those pages. It does so through various
heuristics, which can never be perfect.
What is a "working set" of pages?
A working set is the set of memory chunks required to complete an
operation. For example, the CPU attempts to keep the set of cache
lines required for tight inner loops in L1 cache until the loop completes.
It attempts to keep the set of frequently used functions from various
parts of a program (including shared libraries) in the L2 cache. It does
so both by prefetching cache lines it predicts it may need soon, and by
making decisions about which cache lines to discard and which to keep when
making space to load new cache lines.
The page fault handler attempts to keep each currently running process's
working set of pages in physical memory until the process blocks awaiting
input or exits. Unused portions of program code may never even be loaded
on a given program run (such as an "options" menu for a program that isn't
currently being configured, or portions of generic shared libraries which
this program doesn't actually use).
The working set is determined dynamically at runtime, and can change
over time as a program does different things.
The objective of page stealing is to keep the "working set" of pages in
fast physical memory, allowing processes to "race to quiescence" where
the system completes its current tasks quickly and settles down into
an idle state waiting for the next thing to do. From this point of view,
physical memory can be seen as a cache both for swap pages and for
executables in the filesystem. The task of keeping the working set in
physical memory (and avoiding page faults that trigger I/O) is analogous
to the CPU's task of keeping the appropriate contents in L1 and L2 caches.
What is thrashing?
In low memory situations, each new allocation involves stealing an in-use
page from elsewhere, saving its current contents, and loading new contents.
When that page is again referenced, another page must be stolen to replace
it, saving the new contents and reloading the old contents.
It essentially means that the working set required to service the main
loops of the programs the system is running are larger than available
physical memory, either because physical memory is tied up doing something
else or because the working set is just that big.
This can lead to a state where the CPU generates a constant stream of
page faults, and spends most of its time sitting idle, waiting for I/O to
service those page faults.
This is often called "swap thrashing", and in some ways is the result of
a failure of the system's swap file.
If the swap file is too small (or entirely absent), the system can only
steal pages from file backed mappings. Since every executable program
and shared library is a file backed mapping, this means the system yanks
executable pages, which is generally faults back in fairly rapidly since
they tend to get used a lot. This can quickly lead to thrasing.
The other way to encourage swap thrashing is by having too large of a swap
file, so that programs that query available memory see huge amounts of swap
space and try to use it. The system's available physical memory and I/O
bandwidth don't change with the size of the swap file, so attempts to use
any significant portion of that swap space result memory accesses occuring at
disk I/O speed (four orders of magnitude slower than main memory, stretching
each 1/10th of a second out to about two minutes).
What is the Out Of Memory (OOM) killer?
If the system ever truly ran out of physical memory, it could reach a state
where every process is waiting for some other process to release a page
before it could continue. This deadlock situation would freeze the system.
Before this happened, the system would start thrashing, where it would
slow itself to a crawl by spending all its time constantly stealing pages
only to steal them back again immediately. This situation is almost as
bad as true deadlock, slowing response time to useless levels (five or ten
minute latency on normally instantaneous responses is not unusual during
swap thrashing; this is assuming your operation does not time out instead).
A system that enters swap thrashing may take hours to recover (assuming
a backlog of demands does not emerge as it fails to service them, preventing
it from ever recovering). Or it can take just as long to proceed to
a true deadlock (where the flood of swap I/O stops because the CPU is pegged
at 100% searching for the next page to steal, never finding one, and thus
stops scheduling new I/O).
To avoid either situation, Linux introduced the OOM killer. When it
detects the system has entered swap thrashing, it heuristically determines
a process to kill to free up pages. It can also be configured to reboot
the entire system instead of selecting a specific process to kill.
The OOM killer's process-killing capability is a reasonable way to deal with
runaway processes and "fork bombs", but in the absence of a clearly
malfunctioning process that is truly "at fault", killing any process is
often unacceptable.
Note that the OOM killer doesn't wait for a true memory exhaustion to
deadlock the system, both because the system is effectively down while
thrashing, and because a paralyzed system might not be able to run even
the OOM killer.
The OOM killer's process killing heuristics are a reasonable way to deal with
runaway processes and "fork bombs", but in the absence of a clearly
malfunctioning process that is truly "at fault", killing any process is
often unacceptable. Developers often argue about the choice of processes
to kill, and exactly when the thrashing is bad enough to trigger the OOM
killer and when to allow the system to attempt to work its way through
to recovery. Both of these heuristics are by their nature imperfect,
because they attempt to predict the future.
In general, developers try to avoid triggering the OOM killer, and treat
its occurrence as the userspace equivalent of a kernel panic(). The system
got into an untenable state, it might be good to find out why and prevent
its recurrence.
Why is "strict overcommit" a dumb idea?
People who don't understand how virtual memory works often insist on
tracking the relationship between virtual and physical memory, and attempting
to enforce some correspondence between them (when there isn't one), instead
of controlling their programs' behavior.
Many common unix programming idioms create large virtual memory
ranges with the potential to consume a lot of physical memory, but
never realize that potential. Linux allows the system to "overcommit"
memory, creating memory mappings that promise more physical memory than
the system could actually deliver.
For example, the fork/exec combo creates transient virtual memory usage
spikes, which go away again almost immediately without ever breaking the
copy on write status of most of the pages in the forked page tables. Thus
if a large process forks off a smaller process, enormous physical memory
demands threaten to happen (as far as overcommit is concerned), but never
materialize.
Dynamic linking raises similar issues: the dynamic linker maps executable
files and shared libraries MAP_PRIVATE, which allows it to write to those
pages to perform the dynamic linking fixups allowing the shared library
calls to connect to the shared library. In theory, there could be a
call to functions or data in a shared library within every page of the
executable (and thus the entire mapping could be converted to anonymous
memory by the copy on write actions of the dynamic linker). And since
shared libraries can call other shared libraries, those could require
private physical memory for their entire mapping too.
In reality, that doesn't happen. It would be incredibly inefficient and
defeat the purpose of using shared libraries in the first place. Most
shared libraries are compiled as Position Independent Code (PIC), and
some executables are Position Independent Executalbles (PIE), which
groups
People who don't understand how virtual memory works often insist on
tracking the relationship between virtual and physical memory, and attempting
to enforce some correspondence between them (when there isn't one). Instead
of designing their programs with predictable and controllable behavior, they
try to make the operating system predict the future. This doesn't work.
Strict overcommit encourages the addition of gigabytes (even terabytes)
of swap space, which leads to swap thrasing if it is ever used. Systems
with large amounts of swap space can literally thrash for days, during which
they perform less computation than they could perform in a single minute
during non-thrashing operation (such as if the OOM killer triggered a
reboot).
What is the appeal of huge pages?
The CPU has a limited number of TLB entries. A huge page allows a single TLB
entry to translate addresses for a large amount of contiguous physical
memory. (For example, the entire Linux kernel fits within a single 2
megabyte "huge page" on x86 systems. Keeping the entire kernel in a
single TLB entry means that calling into the kernel doesn't flush the
userspace mappings out of the TLB.)
Using huge pages means the MMU spends less time walking page tables to refill
the TLB, and can lead to about a 10% performance increase if used
correctly.
What are memory zones and "high memory"?
http://kerneltrap.org/node/2450
http://linux-mm.org/HighMemory
http://www.cs.columbia.edu/~smb/classes/s06-4118/l19.pdf
http://book.opensourceproject.org.cn/kernel/kernelpri/opensource/0131181637/ch04lev1sec2.html
### reference
https://landley.net/writing/memory-faq.txt
muahao@aliyun.com
