diff mbox series

[v3,2/2] ksm: add profit monitoring documentation

Message ID 20220824070821.220092-1-xu.xin16@zte.com.cn (mailing list archive)
State New
Headers show
Series ksm: count allocated rmap_items and update documentation | expand

Commit Message

CGEL Aug. 24, 2022, 7:08 a.m. UTC 
Add the description of KSM profit and how to determine it separately
in system-wide range and inner a single process.

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>
---
 Documentation/admin-guide/mm/ksm.rst | 36 ++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

Comments

Bagas Sanjaya Aug. 24, 2022, 9:38 a.m. UTC | #1 
On Wed, Aug 24, 2022 at 07:08:21AM +0000, xu xin wrote:
> +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_sharing * sizeof(page) -
> +			  ksm_rmp_items * sizeof(rmap_item).
> +

The profit formula above can be put into code blocks. Also, align the
numbered list texts, like:

---- >8 ----

diff --git a/Documentation/admin-guide/mm/ksm.rst b/Documentation/admin-guide/mm/ksm.rst
index 40bc11f6fa15fa..7e3092fe407e37 100644
--- a/Documentation/admin-guide/mm/ksm.rst
+++ b/Documentation/admin-guide/mm/ksm.rst
@@ -194,22 +194,22 @@ 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:
+   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``.
+   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:
+   following approximate calculation::
 
 	process_profit =~ ksm_merging_sharing * sizeof(page) -
 			  ksm_rmp_items * sizeof(rmap_item).
 
-where both ksm_merging_sharing and ksm_rmp_items are shown under the directory
-``/proc/<pid>/``.
+   where both ksm_merging_sharing and ksm_rmp_items are shown under the
+   directory ``/proc/<pid>/``.
 
 From the perspective of application, a high ratio of ``ksm_rmp_items`` to
 ``ksm_merging_sharing`` means a bad madvise-applied policy, so developers or

Thanks.
CGEL Aug. 24, 2022, 12:52 p.m. UTC | #2 
On Wed, Aug 24, 2022 at 04:38:26PM +0700, Bagas Sanjaya wrote:
> On Wed, Aug 24, 2022 at 07:08:21AM +0000, xu xin wrote:
> > +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_sharing * sizeof(page) -
> > +			  ksm_rmp_items * sizeof(rmap_item).
> > +
> 
> The profit formula above can be put into code blocks. Also, align the
> numbered list texts, like:

Thank you for corrections, done.

> 
> ---- >8 ----
> 
> diff --git a/Documentation/admin-guide/mm/ksm.rst b/Documentation/admin-guide/mm/ksm.rst
> index 40bc11f6fa15fa..7e3092fe407e37 100644
> --- a/Documentation/admin-guide/mm/ksm.rst
> +++ b/Documentation/admin-guide/mm/ksm.rst
> @@ -194,22 +194,22 @@ 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:
> +   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``.
> +   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:
> +   following approximate calculation::
>  
>  	process_profit =~ ksm_merging_sharing * sizeof(page) -
>  			  ksm_rmp_items * sizeof(rmap_item).
>  
> -where both ksm_merging_sharing and ksm_rmp_items are shown under the directory
> -``/proc/<pid>/``.
> +   where both ksm_merging_sharing and ksm_rmp_items are shown under the
> +   directory ``/proc/<pid>/``.
>  
>  From the perspective of application, a high ratio of ``ksm_rmp_items`` to
>  ``ksm_merging_sharing`` means a bad madvise-applied policy, so developers or
> 
> Thanks.
> 
> -- 
> An old man doll... just what I always wanted! - Clara
diff mbox series

Patch

diff --git a/Documentation/admin-guide/mm/ksm.rst b/Documentation/admin-guide/mm/ksm.rst
index b244f0202a03..40bc11f6fa15 100644
--- a/Documentation/admin-guide/mm/ksm.rst
+++ b/Documentation/admin-guide/mm/ksm.rst
@@ -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
 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_sharing * sizeof(page) -
+			  ksm_rmp_items * sizeof(rmap_item).
+
+where both ksm_merging_sharing and ksm_rmp_items are shown under the directory
+``/proc/<pid>/``.
+
+From the perspective of application, a high ratio of ``ksm_rmp_items`` to
+``ksm_merging_sharing`` 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_rmp_items/ksm_merging_sharing`` 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
 =====================