DESCRIPTION
The Translation Look-aside Buffer (TLB) is a microprocessor feature
for virtual memory, where the most recent physical to virtual address
translations are cached, in the expectation that these translations
are likely to be needed again soon.
This is based on the principles of spatial and temporal locality
of address references in programs.
Historically, the TLB was entirely managed within hardware to
achieve speed optimizations while sacrificing the flexibility
of software implementations.
For example, easily changed algorithms or table implementations.
In recent years, the flexibility of a software implementation
of the TLB has regained importance over pure hardware speed.
Specifically, the idea of logical grouping of physical frames
(whose size is fixed in hardware) into 'superpages' or 'large pages',
that can be represented in software TLB algorithms using a single
base address translation for many physical frames, significantly
reduces the lost cycles due to page faults (assuming reasonable
spatial and temporal locality).
For example, consider a scientific application working on an
array where each element requires 1 KB of memory.
Using the usual 4 KB physical frame size and referencing the array
sequentially causes a page fault that requires the page be
read into memory from disk or swap, and loads the TLB with the
frame base address translation at every fifth element.
If a user application does not use the
chatr
command to specify a page size for the program text and data segments,
the kernel automatically selects a page size based on system configuration
and object size.
This selected size is then compared to the maximum page size defined
by the
vps_ceiling
tunable, and if the selected size is larger, the value of
vps_ceiling
is used instead.
Then, the value is compared against the minimum page size as
set by
vps_pagesize,
and the larger of the two values is used.
Who is Expected to Change This Tunable?
Anyone.
Restrictions on Changing
Changes to this tunable take effect at the next reboot.
When Should the Value of This Tunable Be Raised?
This tunable can be raised when processes on the system
access their text and data in a regular fashion,
and over a range of data larger than the current value.
For example, if this tunable is set to 16 KBs, but
almost every process on the system repeatedly works with a
four or five distinct 256 KB data sets, then
raising the tunable to 256 would reduce the page faulting
for these processes because 16 of the previously 16 KB
pages are now addressed by a single 256 KB translation.
Average system behaviour is not likely to display uniformity
of memory access and the optimal value is not easy to determine,
so this tunable only represents the upper value for the kernel
heuristic and may not change the actual system behaviour.
What Are the Side Effects of Raising the Value?
Memory allocations will require larger groups of contiguous pages,
if either
vps_pagesize
is also raised or the kernel heuristic chooses a larger value.
This can lead to undesired behaviour.
For example, when a program is reading in the last 4 KBs of
code from disk with the default value, this means 16 KBs
of contiguous physical memory must be found and set up with the
appropriate virtual translation, even though, only 4 KBs
of data will actually be on it.
Consider the maximum, where 64 megabytes of contiguous physical
memory is allocated for every new virtual page the program uses,
even if, only 4 KBs of that is actually used.
Besides the wasted physical memory here, there is also an issue
of delays due to fragmentation that many contiguous frames of
physical memory may not be available and a process may be stalled
waiting on the allocation when the amount of memory it actually
needs is available.
Therefore, it is best to only raise this tunable if you know
precisely the memory usage of the system.
In general, increasing the variable page size on a per application
basis for known applications, such as, databases which scan large
amounts of data with only one page fault, is a much better practice.
When Should the Value of This Tunable Be Lowered?
The tunable should be lowered if physical memory fragmentation
is preventing small memory processes from running due to waiting
on contiguous chunks of memory, or if the overall system usage
of memory displays poor spatial locality (virtual accesses are
not close to each other) producing wasted physical frames.
What Are the Side Effects of Lowering the Value?
Applications such as databases will suffer more page faults to
get their working set into memory, but this can be handled by using
chatr
with the appropriate application.
What Other Tunables Should Be Changed at the Same Time?
vps_pagesize
should be considered, being the minimum bound on the kernel
heuristic range.
Printable version
