mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson
synced 2025-09-04 02:25:58 +00:00
ksm: add profit monitoring documentation
Add the description of KSM profit and how to determine it separately in system-wide range and inner a single process. Link: https://lkml.kernel.org/r/20220830144003.299870-1-xu.xin16@zte.com.cn Signed-off-by: xu xin <xu.xin16@zte.com.cn> Reviewed-by: Xiaokai Ran <ran.xiaokai@zte.com.cn> Reviewed-by: Yang Yang <yang.yang29@zte.com.cn> Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Hugh Dickins <hughd@google.com> Cc: Izik Eidus <izik.eidus@ravellosystems.com> Cc: Matthew Wilcox <willy@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
This commit is contained in:
parent
cb4df4cae4
commit
21b7bdb504
@ -184,6 +184,42 @@ The maximum possible ``pages_sharing/pages_shared`` ratio is limited by the
|
|||||||
``max_page_sharing`` tunable. To increase the ratio ``max_page_sharing`` must
|
``max_page_sharing`` tunable. To increase the ratio ``max_page_sharing`` must
|
||||||
be increased accordingly.
|
be increased accordingly.
|
||||||
|
|
||||||
|
Monitoring KSM profit
|
||||||
|
=====================
|
||||||
|
|
||||||
|
KSM can save memory by merging identical pages, but also can consume
|
||||||
|
additional memory, because it needs to generate a number of rmap_items to
|
||||||
|
save each scanned page's brief rmap information. Some of these pages may
|
||||||
|
be merged, but some may not be abled to be merged after being checked
|
||||||
|
several times, which are unprofitable memory consumed.
|
||||||
|
|
||||||
|
1) How to determine whether KSM save memory or consume memory in system-wide
|
||||||
|
range? Here is a simple approximate calculation for reference::
|
||||||
|
|
||||||
|
general_profit =~ pages_sharing * sizeof(page) - (all_rmap_items) *
|
||||||
|
sizeof(rmap_item);
|
||||||
|
|
||||||
|
where all_rmap_items can be easily obtained by summing ``pages_sharing``,
|
||||||
|
``pages_shared``, ``pages_unshared`` and ``pages_volatile``.
|
||||||
|
|
||||||
|
2) The KSM profit inner a single process can be similarly obtained by the
|
||||||
|
following approximate calculation::
|
||||||
|
|
||||||
|
process_profit =~ ksm_merging_pages * sizeof(page) -
|
||||||
|
ksm_rmap_items * sizeof(rmap_item).
|
||||||
|
|
||||||
|
where ksm_merging_pages is shown under the directory ``/proc/<pid>/``,
|
||||||
|
and ksm_rmap_items is shown in ``/proc/<pid>/ksm_stat``.
|
||||||
|
|
||||||
|
From the perspective of application, a high ratio of ``ksm_rmap_items`` to
|
||||||
|
``ksm_merging_pages`` means a bad madvise-applied policy, so developers or
|
||||||
|
administrators have to rethink how to change madvise policy. Giving an example
|
||||||
|
for reference, a page's size is usually 4K, and the rmap_item's size is
|
||||||
|
separately 32B on 32-bit CPU architecture and 64B on 64-bit CPU architecture.
|
||||||
|
so if the ``ksm_rmap_items/ksm_merging_pages`` ratio exceeds 64 on 64-bit CPU
|
||||||
|
or exceeds 128 on 32-bit CPU, then the app's madvise policy should be dropped,
|
||||||
|
because the ksm profit is approximately zero or negative.
|
||||||
|
|
||||||
Monitoring KSM events
|
Monitoring KSM events
|
||||||
=====================
|
=====================
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user