[PATCH v4 0/2] ksm: count allocated rmap_items and update documentation

[PATCH v4 0/2] ksm: count allocated rmap_items and update documentation

[xu xin]

KSM can save memory by merging identical pages, but also can consume
additional memory, because it needs to generate rmap_items to save
each scanned page's brief rmap information.

To determine how beneficial the ksm-policy (like madvise), they are using
brings, so we add a new interface /proc/<pid>/ksm_alloced_items for each
process to indicate the total allocated ksm rmap_items of this process.

The detailed description can be seen in the following patches' commit message.


-----------
v3->v4:
Fix the wrong writing format and some misspellings of the related documentaion.

v2->v3:
remake the patches based on the latest linux-next branch.

v1->v2:
Add documentation for the new item.



*** BLURB HERE ***

xu xin (2):
  ksm: count allocated ksm rmap_items for each process
  ksm: add profit monitoring documentation

 Documentation/admin-guide/mm/ksm.rst | 36 ++++++++++++++++++++++++++++
 fs/proc/base.c                       | 15 ++++++++++++
 include/linux/mm_types.h             |  5 ++++
 mm/ksm.c                             |  2 ++
 4 files changed, 58 insertions(+)


base-commit: 68a00424bf69036970ced7930f9e4d709b4a6423
-- 
2.25.1

[PATCH v4 1/2] ksm: count allocated ksm rmap_items for each process

[xu xin]

KSM can save memory by merging identical pages, but also can consume
additional memory, because it needs to generate 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.

The information about whether KSM save memory or consume memory in
system-wide range can be determined by the comprehensive calculation
of pages_sharing, pages_shared, pages_unshared and pages_volatile.
A simple approximate calculation:

	profit =~ pages_sharing * sizeof(page) - (all_rmap_items) *
	         sizeof(rmap_item);

where all_rmap_items equals to the sum of pages_sharing, pages_shared,
pages_unshared and pages_volatile.

But we cannot calculate this kind of ksm profit inner single-process wide
because the information of ksm rmap_item's number of a process is lacked.
For user applications, if this kind of information could be obtained,
it helps upper users know how beneficial the ksm-policy (like madvise)
they are using brings, and then optimize their app code. For example,
one application madvise 1000 pages as MERGEABLE, while only a few pages
are really merged, then it's not cost-efficient.

So we add a new interface /proc/<pid>/ksm_rmp_items for each process to
indicate the total allocated ksm rmap_items of this process. Similarly,
we can calculate the ksm profit approximately for a single-process by:

	profit =~ ksm_merging_pages * sizeof(page) - ksm_rmp_items *
		 sizeof(rmap_item);

where ksm_merging_pages and ksm_rmp_items are both under /proc/<pid>/.

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>
Signed-off-by: CGEL ZTE <cgel.zte@gmail.com>
---
 fs/proc/base.c           | 15 +++++++++++++++
 include/linux/mm_types.h |  5 +++++
 mm/ksm.c                 |  2 ++
 3 files changed, 22 insertions(+)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index 4ead8cf654e4..9977e17885c2 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -3199,6 +3199,19 @@ static int proc_pid_ksm_merging_pages(struct seq_file *m, struct pid_namespace *
 
 	return 0;
 }
+static int proc_pid_ksm_rmp_items(struct seq_file *m, struct pid_namespace *ns,
+				struct pid *pid, struct task_struct *task)
+{
+	struct mm_struct *mm;
+
+	mm = get_task_mm(task);
+	if (mm) {
+		seq_printf(m, "%lu\n", mm->ksm_rmp_items);
+		mmput(mm);
+	}
+
+	return 0;
+}
 #endif /* CONFIG_KSM */
 
 #ifdef CONFIG_STACKLEAK_METRICS
@@ -3334,6 +3347,7 @@ static const struct pid_entry tgid_base_stuff[] = {
 #endif
 #ifdef CONFIG_KSM
 	ONE("ksm_merging_pages",  S_IRUSR, proc_pid_ksm_merging_pages),
+	ONE("ksm_rmp_items",  S_IRUSR, proc_pid_ksm_rmp_items),
 #endif
 };
 
@@ -3671,6 +3685,7 @@ static const struct pid_entry tid_base_stuff[] = {
 #endif
 #ifdef CONFIG_KSM
 	ONE("ksm_merging_pages",  S_IRUSR, proc_pid_ksm_merging_pages),
+	ONE("ksm_rmp_items",  S_IRUSR, proc_pid_ksm_rmp_items),
 #endif
 };
 
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index d6ec33438dc1..a2a8da1ccb31 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -656,6 +656,11 @@ struct mm_struct {
 		 * merging.
 		 */
 		unsigned long ksm_merging_pages;
+		/*
+		 * Represent how many pages are checked for ksm merging
+		 * including merged and not merged.
+		 */
+		unsigned long ksm_rmp_items;
 #endif
 #ifdef CONFIG_LRU_GEN
 		struct {
diff --git a/mm/ksm.c b/mm/ksm.c
index a98bc3beb874..66d686039010 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -387,6 +387,7 @@ static inline struct rmap_item *alloc_rmap_item(void)
 static inline void free_rmap_item(struct rmap_item *rmap_item)
 {
 	ksm_rmap_items--;
+	rmap_item->mm->ksm_rmp_items--;
 	rmap_item->mm = NULL;	/* debug safety */
 	kmem_cache_free(rmap_item_cache, rmap_item);
 }
@@ -2231,6 +2232,7 @@ static struct rmap_item *get_next_rmap_item(struct mm_slot *mm_slot,
 	if (rmap_item) {
 		/* It has already been zeroed */
 		rmap_item->mm = mm_slot->mm;
+		rmap_item->mm->ksm_rmp_items++;
 		rmap_item->address = addr;
 		rmap_item->rmap_list = *rmap_list;
 		*rmap_list = rmap_item;

base-commit: 68a00424bf69036970ced7930f9e4d709b4a6423
-- 
2.25.1

Re: [PATCH v4 1/2] ksm: count allocated ksm rmap_items for each process

[Matthew Wilcox]

On Wed, Aug 24, 2022 at 12:46:15PM +0000, xu xin wrote:
>  #ifdef CONFIG_KSM
>  	ONE("ksm_merging_pages",  S_IRUSR, proc_pid_ksm_merging_pages),
> +	ONE("ksm_rmp_items",  S_IRUSR, proc_pid_ksm_rmp_items),

You misspelled "rmap" in the file name.

> +		/*
> +		 * Represent how many pages are checked for ksm merging
> +		 * including merged and not merged.
> +		 */
> +		unsigned long ksm_rmp_items;

Also here.

Re: [PATCH v4 1/2] ksm: count allocated ksm rmap_items for each process

[Alexey Dobriyan]

On Wed, Aug 24, 2022 at 12:46:15PM +0000, xu xin wrote:
> +static int proc_pid_ksm_rmp_items(struct seq_file *m, struct pid_namespace *ns,
> +				struct pid *pid, struct task_struct *task)
> +{
> +	struct mm_struct *mm;
> +
> +	mm = get_task_mm(task);
> +	if (mm) {
> +		seq_printf(m, "%lu\n", mm->ksm_rmp_items);
> +		mmput(mm);
> +	}
> +
> +	return 0;
> +}
>  #endif /* CONFIG_KSM */
>  
>  #ifdef CONFIG_STACKLEAK_METRICS
> @@ -3334,6 +3347,7 @@ static const struct pid_entry tgid_base_stuff[] = {
>  #endif
>  #ifdef CONFIG_KSM
>  	ONE("ksm_merging_pages",  S_IRUSR, proc_pid_ksm_merging_pages),
> +	ONE("ksm_rmp_items",  S_IRUSR, proc_pid_ksm_rmp_items),
>  #endif

Another tiny /proc/$pid/ file?

Guys, this problem with "find /proc" instantiating megabytes is not
getting better only worse.

How did KSM didn't get its own /proc/*/ksm file with many values?

Maybe add /proc/*/ksm and start filling it with stuff leaving
/proc/*/ksm_merging_pages alone?

[PATCH v4 2/2] ksm: add profit monitoring documentation

[xu xin]

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(+)

diff --git a/Documentation/admin-guide/mm/ksm.rst b/Documentation/admin-guide/mm/ksm.rst
index b244f0202a03..c2893027cbe6 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_pages * sizeof(page) -
+			  ksm_rmp_items * sizeof(rmap_item).
+
+   where both ksm_merging_pages 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_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_rmp_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
 =====================
 
-- 
2.25.1

Re: [PATCH v4 2/2] ksm: add profit monitoring documentation

[Bagas Sanjaya]

On 8/24/22 19:48, xu xin wrote:
> +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_rmp_items * sizeof(rmap_item).
> +
> +   where both ksm_merging_pages 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_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_rmp_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
>  =====================
>  

LGTM.

Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>

-- 
An old man doll... just what I always wanted! - Clara

Re: [PATCH v4 0/2] ksm: count allocated rmap_items and update documentation

[Matthew Wilcox]

On Wed, Aug 24, 2022 at 12:45:12PM +0000, xu xin wrote:
> v3->v4:
> Fix the wrong writing format and some misspellings of the related documentaion.
> 
> v2->v3:
> remake the patches based on the latest linux-next branch.
> 
> v1->v2:
> Add documentation for the new item.

Don't send multiple versions of a patch series per day.  This fragments
review and makes it harder to know what's going on with the patch series.
Leave it at least a day between versions, preferably a week.