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

From: David Hildenbrand
Date: Fri Apr 26 2024 - 04:13:17 EST


On 26.04.24 03:46, xu.xin16@xxxxxxxxxx wrote:
From: xu xin <xu.xin16@xxxxxxxxxx>

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

KSM_mergeable: yes/no
whether the process'mm is added by madvise() into the candidate list
of KSM or not.
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.


Thinking about it, we should avoid exposing internal toggles with unclear semantics to the user. See below.

Changelog
=========
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@xxxxxxxxxx>
---
fs/proc/base.c | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index 18550c071d71..50e808ffcda4 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -3217,6 +3217,10 @@ static int proc_pid_ksm_stat(struct seq_file *m, struct pid_namespace *ns,
seq_printf(m, "ksm_zero_pages %lu\n", mm->ksm_zero_pages);
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_mergeable: %s\n",
+ test_bit(MMF_VM_MERGEABLE, &mm->flags) ? "yes" : "no");

All it *currently* means is "we called __ksm_enter()" once. It does not mean that KSM is still enabled for that process and that any VMA would be considered for merging.

I don't think we should expose this.

That information can be more reliably had by looking at

"/proc/pid/smaps" and looking for "mg".

Which tells you exactly if any VMA (and which) is currently applicable to KSM.


+ seq_printf(m, "KSM_merge_any: %s\n",
+ test_bit(MMF_VM_MERGE_ANY, &mm->flags) ? "yes" : "no");

This makes more sense to export. It's the same as reading prctl(PR_GET_MEMORY_MERGE).

The man page [1] calls it simply "KSM has been enabled for this process", so process-wide KSM compared to per-VMA KSM.

"KSM_enabled:"

*might* be more reasonable in the context of PR_SET_MEMORY_MERGE.

It wouldn't tell though if KSM is enabled on the system, though.


[1] https://lore.kernel.org/linux-mm/20230227220206.436662-1-shr@xxxxxxxxxxxx/T/

--
Cheers,

David / dhildenb