diff mbox series

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

Message ID 20241203192633836RVHhkoK1Amnqjt84D4Ryd@zte.com.cn (mailing list archive)
State New
Headers show
Series [linux-next,v4] ksm: add ksm involvement information for each process | expand

Commit Message

xu.xin16@zte.com.cn Dec. 3, 2024, 11:26 a.m. UTC
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(+)

Comments

Andrew Morton Dec. 4, 2024, 12:56 a.m. UTC | #1
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;
> +}
David Hildenbrand Dec. 10, 2024, 8:05 p.m. UTC | #2
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.
diff mbox series

Patch

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 -