DESCRIPTION
Swap space in the kernel is managed using 'chunks' of physical
device space.
These chunks contain one or more (usually more) pages of memory,
but provide another layer of indexing (similar to
inodes
in file systems) to keep the global swap table relatively
small, as opposed to a large table indexed by swap page.
swchunk
controls the size in physical disk blocks (which are defined as
1 KB) for each chunk.
Combining this information with the value of
maxswapchunks
(the maximum number of swap chunks in the swap table) provides
the total bytes of swap space manageable by the system.
The way to think of
swchunk
is not as the size of the I/O transactions in the swap system
(in disk blocks), but as the number of blocks that will be placed
on one swap device (or file system) before moving to the next
device (assuming all priorities are equal).
This spreads the swap space over any devices and is called
swap
interleaving.
Swap interleaving spreads out the swap over many devices and
reduces the possibility of one single device becoming a
bottleneck for the entire system when swap usage is heavy.
Who is Expected to Change This Tunable?
This tunable should only be modified by those with a
complete knowledge of both kernel behavior and underlying
device hardware.
Restrictions on Changing
Changes to this tunable take effect at the next reboot.
When Should the Value of This Tunable Be Raised?
If
maxswapchunks
has already been raised to its limit and the system owner wishes
to add more swap to the system, but the additional swap chunks
needed are unavailable, raising this tunable will work around
the problem.
By increasing the size of each chunk, fewer total chunks are needed.
What Are the Side Effects of Raising the Value?
The second level of the swap table (used to track pages within
a chunk) will increase, resulting in more memory used by the kernel.
If
maxswapchunks
is reduced to have fewer larger chunks to represent the same swap
space, this will be offset by the smaller first level of the swap table.
If
swchunk
is being increased to allow for mapping of a larger swap space, increased
memory usage by the kernel to track the swap space is unavoidable.
This means that more swap is allocated to each device (or file system)
in the round-robin interleaving scheme and all priorities are equal.
If
maxswapchunks
is not at its maximum, increasing
swchunck
instead of
maxswapchunks
could hinder system performance by creating unneeded I/O bottlenecks;
where, two pages that were in different chunks using the smaller value
and were previously on different swap devices and thus accessible
independently of one another (with no read head or controller issues)
are now on the same device and slowing down access time for the second page.
When Should the Value of This Tunable Be Lowered?
If the amount of swap space mappable by the system is much larger than
the total amount of swap space which is attached (or going to be
attached) to the system, which is calculable by multiplying
maxswapchunks*
swchunk*
1KB, then kernel memory usage can be reduced by lowering either
swchunk
or
maxswapchunks
to fit the actual swap space.
Note that modification of
maxswapchunks
is preferable to
swchunk
unless
swchunk
I/O bottlenecks are being created due to the loss of round-robin interleaving.
What Are the Side Effects of Lowering the Value?
It may have to be raised back if more swap is added to the system
and there is not enough room in the swap table to allow for the
increased space.
If this is not the case, then there is a finer grain of interleaving on
the system (assuming there is more than one swap device) that can provide
a performance gain under heavy swap usage.
What Other Tunable Values Should Be Changed at the Same Time?
maxswapchunks
should be considered when changing this tunable.
Printable version
