179 lines
10 KiB
Plaintext
179 lines
10 KiB
Plaintext
How to use the Kernel Samepage Merging feature
|
|
----------------------------------------------
|
|
|
|
KSM is a memory-saving de-duplication feature, enabled by CONFIG_KSM=y,
|
|
added to the Linux kernel in 2.6.32. See mm/ksm.c for its implementation,
|
|
and http://lwn.net/Articles/306704/ and http://lwn.net/Articles/330589/
|
|
|
|
The KSM daemon ksmd periodically scans those areas of user memory which
|
|
have been registered with it, looking for pages of identical content which
|
|
can be replaced by a single write-protected page (which is automatically
|
|
copied if a process later wants to update its content).
|
|
|
|
KSM was originally developed for use with KVM (where it was known as
|
|
Kernel Shared Memory), to fit more virtual machines into physical memory,
|
|
by sharing the data common between them. But it can be useful to any
|
|
application which generates many instances of the same data.
|
|
|
|
KSM only merges anonymous (private) pages, never pagecache (file) pages.
|
|
KSM's merged pages were originally locked into kernel memory, but can now
|
|
be swapped out just like other user pages (but sharing is broken when they
|
|
are swapped back in: ksmd must rediscover their identity and merge again).
|
|
|
|
KSM only operates on those areas of address space which an application
|
|
has advised to be likely candidates for merging, by using the madvise(2)
|
|
system call: int madvise(addr, length, MADV_MERGEABLE).
|
|
|
|
The app may call int madvise(addr, length, MADV_UNMERGEABLE) to cancel
|
|
that advice and restore unshared pages: whereupon KSM unmerges whatever
|
|
it merged in that range. Note: this unmerging call may suddenly require
|
|
more memory than is available - possibly failing with EAGAIN, but more
|
|
probably arousing the Out-Of-Memory killer.
|
|
|
|
If KSM is not configured into the running kernel, madvise MADV_MERGEABLE
|
|
and MADV_UNMERGEABLE simply fail with EINVAL. If the running kernel was
|
|
built with CONFIG_KSM=y, those calls will normally succeed: even if the
|
|
the KSM daemon is not currently running, MADV_MERGEABLE still registers
|
|
the range for whenever the KSM daemon is started; even if the range
|
|
cannot contain any pages which KSM could actually merge; even if
|
|
MADV_UNMERGEABLE is applied to a range which was never MADV_MERGEABLE.
|
|
|
|
If a region of memory must be split into at least one new MADV_MERGEABLE
|
|
or MADV_UNMERGEABLE region, the madvise may return ENOMEM if the process
|
|
will exceed vm.max_map_count (see Documentation/sysctl/vm.txt).
|
|
|
|
Like other madvise calls, they are intended for use on mapped areas of
|
|
the user address space: they will report ENOMEM if the specified range
|
|
includes unmapped gaps (though working on the intervening mapped areas),
|
|
and might fail with EAGAIN if not enough memory for internal structures.
|
|
|
|
Applications should be considerate in their use of MADV_MERGEABLE,
|
|
restricting its use to areas likely to benefit. KSM's scans may use a lot
|
|
of processing power: some installations will disable KSM for that reason.
|
|
|
|
The KSM daemon is controlled by sysfs files in /sys/kernel/mm/ksm/,
|
|
readable by all but writable only by root:
|
|
|
|
pages_to_scan - how many present pages to scan before ksmd goes to sleep
|
|
e.g. "echo 100 > /sys/kernel/mm/ksm/pages_to_scan"
|
|
Default: 100 (chosen for demonstration purposes)
|
|
|
|
sleep_millisecs - how many milliseconds ksmd should sleep before next scan
|
|
e.g. "echo 20 > /sys/kernel/mm/ksm/sleep_millisecs"
|
|
Default: 20 (chosen for demonstration purposes)
|
|
|
|
merge_across_nodes - specifies if pages from different numa nodes can be merged.
|
|
When set to 0, ksm merges only pages which physically
|
|
reside in the memory area of same NUMA node. That brings
|
|
lower latency to access of shared pages. Systems with more
|
|
nodes, at significant NUMA distances, are likely to benefit
|
|
from the lower latency of setting 0. Smaller systems, which
|
|
need to minimize memory usage, are likely to benefit from
|
|
the greater sharing of setting 1 (default). You may wish to
|
|
compare how your system performs under each setting, before
|
|
deciding on which to use. merge_across_nodes setting can be
|
|
changed only when there are no ksm shared pages in system:
|
|
set run 2 to unmerge pages first, then to 1 after changing
|
|
merge_across_nodes, to remerge according to the new setting.
|
|
Default: 1 (merging across nodes as in earlier releases)
|
|
|
|
run - set 0 to stop ksmd from running but keep merged pages,
|
|
set 1 to run ksmd e.g. "echo 1 > /sys/kernel/mm/ksm/run",
|
|
set 2 to stop ksmd and unmerge all pages currently merged,
|
|
but leave mergeable areas registered for next run
|
|
Default: 0 (must be changed to 1 to activate KSM,
|
|
except if CONFIG_SYSFS is disabled)
|
|
|
|
use_zero_pages - specifies whether empty pages (i.e. allocated pages
|
|
that only contain zeroes) should be treated specially.
|
|
When set to 1, empty pages are merged with the kernel
|
|
zero page(s) instead of with each other as it would
|
|
happen normally. This can improve the performance on
|
|
architectures with coloured zero pages, depending on
|
|
the workload. Care should be taken when enabling this
|
|
setting, as it can potentially degrade the performance
|
|
of KSM for some workloads, for example if the checksums
|
|
of pages candidate for merging match the checksum of
|
|
an empty page. This setting can be changed at any time,
|
|
it is only effective for pages merged after the change.
|
|
Default: 0 (normal KSM behaviour as in earlier releases)
|
|
|
|
max_page_sharing - Maximum sharing allowed for each KSM page. This
|
|
enforces a deduplication limit to avoid the virtual
|
|
memory rmap lists to grow too large. The minimum
|
|
value is 2 as a newly created KSM page will have at
|
|
least two sharers. The rmap walk has O(N)
|
|
complexity where N is the number of rmap_items
|
|
(i.e. virtual mappings) that are sharing the page,
|
|
which is in turn capped by max_page_sharing. So
|
|
this effectively spread the the linear O(N)
|
|
computational complexity from rmap walk context
|
|
over different KSM pages. The ksmd walk over the
|
|
stable_node "chains" is also O(N), but N is the
|
|
number of stable_node "dups", not the number of
|
|
rmap_items, so it has not a significant impact on
|
|
ksmd performance. In practice the best stable_node
|
|
"dup" candidate will be kept and found at the head
|
|
of the "dups" list. The higher this value the
|
|
faster KSM will merge the memory (because there
|
|
will be fewer stable_node dups queued into the
|
|
stable_node chain->hlist to check for pruning) and
|
|
the higher the deduplication factor will be, but
|
|
the slowest the worst case rmap walk could be for
|
|
any given KSM page. Slowing down the rmap_walk
|
|
means there will be higher latency for certain
|
|
virtual memory operations happening during
|
|
swapping, compaction, NUMA balancing and page
|
|
migration, in turn decreasing responsiveness for
|
|
the caller of those virtual memory operations. The
|
|
scheduler latency of other tasks not involved with
|
|
the VM operations doing the rmap walk is not
|
|
affected by this parameter as the rmap walks are
|
|
always schedule friendly themselves.
|
|
|
|
stable_node_chains_prune_millisecs - How frequently to walk the whole
|
|
list of stable_node "dups" linked in the
|
|
stable_node "chains" in order to prune stale
|
|
stable_nodes. Smaller milllisecs values will free
|
|
up the KSM metadata with lower latency, but they
|
|
will make ksmd use more CPU during the scan. This
|
|
only applies to the stable_node chains so it's a
|
|
noop if not a single KSM page hit the
|
|
max_page_sharing yet (there would be no stable_node
|
|
chains in such case).
|
|
|
|
The effectiveness of KSM and MADV_MERGEABLE is shown in /sys/kernel/mm/ksm/:
|
|
|
|
pages_shared - how many shared pages are being used
|
|
pages_sharing - how many more sites are sharing them i.e. how much saved
|
|
pages_unshared - how many pages unique but repeatedly checked for merging
|
|
pages_volatile - how many pages changing too fast to be placed in a tree
|
|
full_scans - how many times all mergeable areas have been scanned
|
|
|
|
stable_node_chains - number of stable node chains allocated, this is
|
|
effectively the number of KSM pages that hit the
|
|
max_page_sharing limit
|
|
stable_node_dups - number of stable node dups queued into the
|
|
stable_node chains
|
|
|
|
A high ratio of pages_sharing to pages_shared indicates good sharing, but
|
|
a high ratio of pages_unshared to pages_sharing indicates wasted effort.
|
|
pages_volatile embraces several different kinds of activity, but a high
|
|
proportion there would also indicate poor use of madvise MADV_MERGEABLE.
|
|
|
|
The maximum possible page_sharing/page_shared ratio is limited by the
|
|
max_page_sharing tunable. To increase the ratio max_page_sharing must
|
|
be increased accordingly.
|
|
|
|
The stable_node_dups/stable_node_chains ratio is also affected by the
|
|
max_page_sharing tunable, and an high ratio may indicate fragmentation
|
|
in the stable_node dups, which could be solved by introducing
|
|
fragmentation algorithms in ksmd which would refile rmap_items from
|
|
one stable_node dup to another stable_node dup, in order to freeup
|
|
stable_node "dups" with few rmap_items in them, but that may increase
|
|
the ksmd CPU usage and possibly slowdown the readonly computations on
|
|
the KSM pages of the applications.
|
|
|
|
Izik Eidus,
|
|
Hugh Dickins, 17 Nov 2009
|