[PATCH linux-next v4] ksm: add ksm involvement information for each process

[PATCH linux-next v4] ksm: add ksm involvement information for each process

[xu.xin16]

From: xu xin <xu.xin16@zte.com.cn>

In /proc/<pid>/ksm_stat, Add two extra ksm involvement items including
KSM_mergeable and KSM_merge_any. It helps administrators to
better know the system's KSM behavior at process level.

KSM_mergeable: yes/no
	whether any VMAs of the process'mm are currently applicable to KSM.

KSM_merge_any: yes/no
	whether the process'mm is added by prctl() into the candidate list
	of KSM or not, and fully enabled at process level.

Changelog
=========
v3 -> v4:
    1. Keep the name of ksm items consistent in /proc/pid/ksm_stat.
	   * KSM_mergeable -> ksm_mergeable
	   * KSM_merge_any -> ksm_merge_any
    2. Hold the read lock of mmap while calling ksm_process_mergeable()
    Suggested-by:
    https://lore.kernel.org/all/cec0ed06-b5d0-45aa-ad2b-eaca6dd7bacb@redhat.com/

v2 -> v3:
        Update the KSM_mergeable getting method: loop up if any vma is
        mergeable to KSM.
		https://lore.kernel.org/all/bc0e1cdd-2d9d-437c-8fc9-4df0e13c48c0@redhat.com/

v1 -> v2:
        replace the internal flag names with straightforward strings.
        * MMF_VM_MERGEABLE -> KSM_mergeable
        * MMF_VM_MERGE_ANY -> KSM_merge_any

Signed-off-by: xu xin <xu.xin16@zte.com.cn>
Cc: Wang Yaxin <wang.yaxin@zte.com.cn>
---
 fs/proc/base.c      | 11 +++++++++++
 include/linux/ksm.h |  1 +
 mm/ksm.c            | 19 +++++++++++++++++++
 3 files changed, 31 insertions(+)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index 0edf14a9840e..a50b222a5917 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -3269,6 +3269,7 @@ static int proc_pid_ksm_stat(struct seq_file *m, struct pid_namespace *ns,
 				struct pid *pid, struct task_struct *task)
 {
 	struct mm_struct *mm;
+	int ret = 0;

 	mm = get_task_mm(task);
 	if (mm) {
@@ -3276,6 +3277,16 @@ static int proc_pid_ksm_stat(struct seq_file *m, struct pid_namespace *ns,
 		seq_printf(m, "ksm_zero_pages %ld\n", mm_ksm_zero_pages(mm));
 		seq_printf(m, "ksm_merging_pages %lu\n", mm->ksm_merging_pages);
 		seq_printf(m, "ksm_process_profit %ld\n", ksm_process_profit(mm));
+		seq_printf(m, "ksm_merge_any: %s\n",
+				test_bit(MMF_VM_MERGE_ANY, &mm->flags) ? "yes" : "no");
+		ret = mmap_read_lock_killable(mm);
+		if (ret) {
+			mmput(mm);
+			return ret;
+		}
+		seq_printf(m, "ksm_mergeable: %s\n",
+				ksm_process_mergeable(mm) ? "yes" : "no");
+		mmap_read_unlock(mm);
 		mmput(mm);
 	}

diff --git a/include/linux/ksm.h b/include/linux/ksm.h
index 6a53ac4885bb..d73095b5cd96 100644
--- a/include/linux/ksm.h
+++ b/include/linux/ksm.h
@@ -93,6 +93,7 @@ void folio_migrate_ksm(struct folio *newfolio, struct folio *folio);
 void collect_procs_ksm(const struct folio *folio, const struct page *page,
 		struct list_head *to_kill, int force_early);
 long ksm_process_profit(struct mm_struct *);
+bool ksm_process_mergeable(struct mm_struct *mm);

 #else  /* !CONFIG_KSM */

diff --git a/mm/ksm.c b/mm/ksm.c
index 7ac59cde626c..e87af149d5ee 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -3263,6 +3263,25 @@ static void wait_while_offlining(void)
 #endif /* CONFIG_MEMORY_HOTREMOVE */

 #ifdef CONFIG_PROC_FS
+/*
+ * The process is mergeable only if any VMA (and which) is currently
+ * applicable to KSM.
+ *
+ * The mmap lock must be held in read mode.
+ */
+bool ksm_process_mergeable(struct mm_struct *mm)
+{
+	struct vm_area_struct *vma;
+
+	mmap_assert_locked(mm);
+	VMA_ITERATOR(vmi, mm, 0);
+	for_each_vma(vmi, vma)
+		if (vma->vm_flags & VM_MERGEABLE)
+			return true;
+
+	return false;
+}
+
 long ksm_process_profit(struct mm_struct *mm)
 {
 	return (long)(mm->ksm_merging_pages + mm_ksm_zero_pages(mm)) * PAGE_SIZE -
-- 
2.15.2

Re: [PATCH linux-next v4] ksm: add ksm involvement information for each process

[Andrew Morton]

On Tue, 3 Dec 2024 19:26:33 +0800 (CST) <xu.xin16@zte.com.cn> wrote:

> From: xu xin <xu.xin16@zte.com.cn>
> 
> In /proc/<pid>/ksm_stat, Add two extra ksm involvement items including
> KSM_mergeable and KSM_merge_any. It helps administrators to
> better know the system's KSM behavior at process level.

It's hard for me to judge the usefulness of this.  Please tell us more:
usage examples, what actions have been taken using this information, etc.

> KSM_mergeable: yes/no
> 	whether any VMAs of the process'mm are currently applicable to KSM.

Could we simply display VM_MERGEABLE in /proc/<pid>/maps?

> KSM_merge_any: yes/no
> 	whether the process'mm is added by prctl() into the candidate list
> 	of KSM or not, and fully enabled at process level.
> 
> ...
>
>  fs/proc/base.c      | 11 +++++++++++
>  include/linux/ksm.h |  1 +
>  mm/ksm.c            | 19 +++++++++++++++++++

Documentation/admin-guide/mm/ksm.rst will require an update please.

>
> ...
>
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -3269,6 +3269,7 @@ static int proc_pid_ksm_stat(struct seq_file *m, struct pid_namespace *ns,
>  				struct pid *pid, struct task_struct *task)
>  {
>  	struct mm_struct *mm;
> +	int ret = 0;
> 
>  	mm = get_task_mm(task);
>  	if (mm) {
> @@ -3276,6 +3277,16 @@ static int proc_pid_ksm_stat(struct seq_file *m, struct pid_namespace *ns,
>  		seq_printf(m, "ksm_zero_pages %ld\n", mm_ksm_zero_pages(mm));
>  		seq_printf(m, "ksm_merging_pages %lu\n", mm->ksm_merging_pages);
>  		seq_printf(m, "ksm_process_profit %ld\n", ksm_process_profit(mm));
> +		seq_printf(m, "ksm_merge_any: %s\n",
> +				test_bit(MMF_VM_MERGE_ANY, &mm->flags) ? "yes" : "no");
> +		ret = mmap_read_lock_killable(mm);

Could do the locking in ksm_process_mergeable()?

> +		if (ret) {
> +			mmput(mm);
> +			return ret;
> +		}
> +		seq_printf(m, "ksm_mergeable: %s\n",
> +				ksm_process_mergeable(mm) ? "yes" : "no");

Calling seq_printf() after the mmap_read_unlock() would be a little
more scalable.

> +		mmap_read_unlock(mm);
>  		mmput(mm);
>  	}
>
> ...
>
> --- a/mm/ksm.c
> +++ b/mm/ksm.c
> @@ -3263,6 +3263,25 @@ static void wait_while_offlining(void)
>  #endif /* CONFIG_MEMORY_HOTREMOVE */
> 
>  #ifdef CONFIG_PROC_FS
> +/*
> + * The process is mergeable only if any VMA (and which) is currently
> + * applicable to KSM.

That sentence needs revisiting, please.

> + * The mmap lock must be held in read mode.
> + */
> +bool ksm_process_mergeable(struct mm_struct *mm)
> +{
> +	struct vm_area_struct *vma;
> +
> +	mmap_assert_locked(mm);
> +	VMA_ITERATOR(vmi, mm, 0);
> +	for_each_vma(vmi, vma)
> +		if (vma->vm_flags & VM_MERGEABLE)
> +			return true;
> +
> +	return false;
> +}

Re: [PATCH linux-next v4] ksm: add ksm involvement information for each process

[David Hildenbrand]

On 04.12.24 01:56, Andrew Morton wrote:
> On Tue, 3 Dec 2024 19:26:33 +0800 (CST) <xu.xin16@zte.com.cn> wrote:
> 
>> From: xu xin <xu.xin16@zte.com.cn>
>>
>> In /proc/<pid>/ksm_stat, Add two extra ksm involvement items including
>> KSM_mergeable and KSM_merge_any. It helps administrators to
>> better know the system's KSM behavior at process level.
> 
> It's hard for me to judge the usefulness of this.  Please tell us more:
> usage examples, what actions have been taken using this information, etc.

Seconded.

> 
>> KSM_mergeable: yes/no
>> 	whether any VMAs of the process'mm are currently applicable to KSM.
> 
> Could we simply display VM_MERGEABLE in /proc/<pid>/maps?

We indicate in /proc/<pid>/smaps "mg" for VM_MERGEABLE already.

The "nasty" thing about smaps is that it does all the page table walking 
to gather memory statistics, which can be rather expensive.

I was recently asking myself whether we should have a "cheaper" way to 
obtain such details about mappings. /proc/<pid>/maps is likely 
impossible to extend (similarly display flags) I suspect.



-- 
Cheers,

David / dhildenb

Re: [PATCH linux-next v4] ksm: add ksm involvement information for each process

[xu xin]

>> From: xu xin <xu.xin16@zte.com.cn>
>>
>> In /proc/<pid>/ksm_stat, Add two extra ksm involvement items including
>> KSM_mergeable and KSM_merge_any. It helps administrators to
>> better know the system's KSM behavior at process level.
>
>It's hard for me to judge the usefulness of this.  Please tell us more:
>usage examples, what actions have been taken using this information, etc.

Thank you.

They are just simply to improve the observability of KSM at process level,
so that users can know if a certain process has enable KSM.

For example, if without these two items, when we look at
/proc/<pid>/ksm_stat and there's no merging pages found, We are not sure
whether it is because KSM was not enabled or because KSM did not
successfully merge any pages.

>
>> KSM_mergeable: yes/no
>>      whether any VMAs of the process'mm are currently applicable to KSM.
>
>Could we simply display VM_MERGEABLE in /proc/<pid>/maps?

Althrough "mg" in /proc/<pid>/smaps indicate VM_MERGEABLE, it's opaque
and not very obvious for non professionals. 


>>
>>  fs/proc/base.c      | 11 +++++++++++
>>  include/linux/ksm.h |  1 +
>>  mm/ksm.c            | 19 +++++++++++++++++++
>
>Documentation/admin-guide/mm/ksm.rst will require an update please.

Yes, okay. Thank you.

>> --- a/fs/proc/base.c
>> +++ b/fs/proc/base.c
>> @@ -3269,6 +3269,7 @@ static int proc_pid_ksm_stat(struct seq_file *m, struct pid_namespace *ns,
>>                              struct pid *pid, struct task_struct *task)
>>  {
>>      struct mm_struct *mm;
>> +    int ret = 0;
>>
>>      mm = get_task_mm(task);
>>      if (mm) {
>> @@ -3276,6 +3277,16 @@ static int proc_pid_ksm_stat(struct seq_file *m, struct pid_namespace *ns,
>>              seq_printf(m, "ksm_zero_pages %ld\n", mm_ksm_zero_pages(mm));
>>              seq_printf(m, "ksm_merging_pages %lu\n", mm->ksm_merging_pages);
>>              seq_printf(m, "ksm_process_profit %ld\n", ksm_process_profit(mm));
>> +            seq_printf(m, "ksm_merge_any: %s\n",
>> +                            test_bit(MMF_VM_MERGE_ANY, &mm->flags) ? "yes" : "no");
>> +            ret = mmap_read_lock_killable(mm);
>
>Could do the locking in ksm_process_mergeable()?

Well, the reason why it's not placed inside is to prevent future deadlocks caused by someone using
this function incorrectly under lock already held.

Thanks.