OpenSDV
/
original_kernel
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs/vm: ksm: reshuffle text between "sysfs" and "design" sections 

The description of "max_page_sharing" sysfs attribute includes lots of
implementation details that more naturally belong in the "Design"
section.

Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
Mike Rapoport 2018-04-24 09:40:25 +03:00 committed by Jonathan Corbet
parent 064fca37bc
commit 6570c785ea
1 changed files with 30 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

51
Documentation/vm/ksm.rst
View File

@ -133,31 +133,21 @@ use_zero_pages
max_page_sharing max_page_sharing
Maximum sharing allowed for each KSM page. This enforces a Maximum sharing allowed for each KSM page. This enforces a
deduplication limit to avoid the virtual memory rmap lists to deduplication limit to avoid high latency for virtual memory
grow too large. The minimum value is 2 as a newly created KSM operations that involve traversal of the virtual mappings that
page will have at least two sharers. The rmap walk has O(N) share the KSM page. The minimum value is 2 as a newly created
complexity where N is the number of rmap_items (i.e. virtual KSM page will have at least two sharers. The higher this value
mappings) that are sharing the page, which is in turn capped the faster KSM will merge the memory and the higher the
by ``max_page_sharing``. So this effectively spreads the linear deduplication factor will be, but the slower the worst case
O(N) computational complexity from rmap walk context over virtual mappings traversal could be for any given KSM
different KSM pages. The ksmd walk over the stable_node page. Slowing down this traversal means there will be higher
"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 latency for certain virtual memory operations happening during
swapping, compaction, NUMA balancing and page migration, in swapping, compaction, NUMA balancing and page migration, in
turn decreasing responsiveness for the caller of those virtual turn decreasing responsiveness for the caller of those virtual
memory operations. The scheduler latency of other tasks not memory operations. The scheduler latency of other tasks not
involved with the VM operations doing the rmap walk is not involved with the VM operations doing the virtual mappings
affected by this parameter as the rmap walks are always traversal is not affected by this parameter as these
schedule friendly themselves. traversals are always schedule friendly themselves.
stable_node_chains_prune_millisecs stable_node_chains_prune_millisecs
How frequently to walk the whole list of stable_node "dups" How frequently to walk the whole list of stable_node "dups"
@ -240,6 +230,25 @@ if compared to an unlimited list of reverse mappings. It is still
enforced that there cannot be KSM page content duplicates in the enforced that there cannot be KSM page content duplicates in the
stable tree itself. stable tree itself.
The deduplication limit enforced by ``max_page_sharing`` is required
to avoid the virtual memory rmap lists to grow too large. 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 spreads 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.
High values of ``max_page_sharing`` result in faster memory merging
(because there will be fewer stable_node dups queued into the
stable_node chain->hlist to check for pruning) and higher
deduplication factor at the expense of slower worst case for rmap
walks for any KSM page which can happen during swapping, compaction,
NUMA balancing and page migration.
Reference Reference
--------- ---------
.. kernel-doc:: mm/ksm.c .. kernel-doc:: mm/ksm.c