[PATCH] fs/proc/task_mmu: count KSM-placed zero pages in smaps

[PATCH] fs/proc/task_mmu: count KSM-placed zero pages in smaps

[Jinjiang Tu]

When KSM deduplicates a page to the kernel zero page (i.e. when
/sys/kernel/mm/ksm/use_zero_pages=1), it places a zero PTE with the dirty
bit set. vm_normal_page() returns NULL for such PTEs, so smaps_pte_entry()
bails out before reaching smaps_account() and these pages are never counted
into mss->ksm. As a result /proc/<pid>/smaps and smaps_rollup report a KSM
value of 0 even though the region is fully merged.

Count KSM-placed zero pages directly in smaps_pte_entry() using
is_ksm_zero_pte().

Signed-off-by: Jinjiang Tu <tujinjiang@huawei.com>
---
 fs/proc/task_mmu.c  | 3 +++
 include/linux/ksm.h | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index d32408f7cd5e..3f446e9f59b6 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -1061,6 +1061,9 @@ static void smaps_pte_entry(pte_t *pte, unsigned long addr,
 		young = pte_young(ptent);
 		dirty = pte_dirty(ptent);
 		present = true;
+
+		if (is_ksm_zero_pte(ptent))
+			mss->ksm += PAGE_SIZE;
 	} else if (pte_none(ptent)) {
 		smaps_pte_hole_lookup(addr, walk);
 	} else {
diff --git a/include/linux/ksm.h b/include/linux/ksm.h
index d39d0d5483a2..abb41b3b7f4b 100644
--- a/include/linux/ksm.h
+++ b/include/linux/ksm.h
@@ -127,6 +127,8 @@ static inline void ksm_exit(struct mm_struct *mm)
 {
 }
 
+#define is_ksm_zero_pte(pte) false
+
 static inline void ksm_might_unmap_zero_page(struct mm_struct *mm, pte_t pte)
 {
 }
-- 
2.43.0

Re: [PATCH] fs/proc/task_mmu: count KSM-placed zero pages in smaps

[David Hildenbrand (Arm)]

On 7/6/26 14:13, Jinjiang Tu wrote:
> When KSM deduplicates a page to the kernel zero page (i.e. when
> /sys/kernel/mm/ksm/use_zero_pages=1), it places a zero PTE with the dirty
> bit set. vm_normal_page() returns NULL for such PTEs, so smaps_pte_entry()
> bails out before reaching smaps_account() and these pages are never counted
> into mss->ksm. As a result /proc/<pid>/smaps and smaps_rollup report a KSM
> value of 0 even though the region is fully merged.
> 
> Count KSM-placed zero pages directly in smaps_pte_entry() using
> is_ksm_zero_pte().

Hm.

We do expose "ksm_zero_pages" in /proc/<pid>/ksm_stat for calculating the KSM
profit.

Why would we want to expose it here as KSM pages?

An application will notice the difference between "zeropage enabled vs.
disabled" either way because we'll also not account zerpages towards e.g.,
"Anonymous".

So faking that something consumes memory when it actually doesn't consume memory
is wrong?

-- 
Cheers,

David

Re: [PATCH] fs/proc/task_mmu: count KSM-placed zero pages in smaps

[Jinjiang Tu]

在 2026/7/6 21:40, David Hildenbrand (Arm) 写道:
> On 7/6/26 14:13, Jinjiang Tu wrote:
>> When KSM deduplicates a page to the kernel zero page (i.e. when
>> /sys/kernel/mm/ksm/use_zero_pages=1), it places a zero PTE with the dirty
>> bit set. vm_normal_page() returns NULL for such PTEs, so smaps_pte_entry()
>> bails out before reaching smaps_account() and these pages are never counted
>> into mss->ksm. As a result /proc/<pid>/smaps and smaps_rollup report a KSM
>> value of 0 even though the region is fully merged.
>>
>> Count KSM-placed zero pages directly in smaps_pte_entry() using
>> is_ksm_zero_pte().
> Hm.
>
> We do expose "ksm_zero_pages" in /proc/<pid>/ksm_stat for calculating the KSM
> profit.
>
> Why would we want to expose it here as KSM pages?

I wasanalyzing the KSM profit of a process comes from which VMAs. However, 
smaps does not include the savings from ksm_zero_pages, make me fail to 
analyze.

> An application will notice the difference between "zeropage enabled vs.
> disabled" either way because we'll also not account zerpages towards e.g.,
> "Anonymous".
>
> So faking that something consumes memory when it actually doesn't consume memory
> is wrong?

Re: [PATCH] fs/proc/task_mmu: count KSM-placed zero pages in smaps

[Jinjiang Tu]

在 2026/7/6 21:40, David Hildenbrand (Arm) 写道:
> On 7/6/26 14:13, Jinjiang Tu wrote:
>> When KSM deduplicates a page to the kernel zero page (i.e. when
>> /sys/kernel/mm/ksm/use_zero_pages=1), it places a zero PTE with the dirty
>> bit set. vm_normal_page() returns NULL for such PTEs, so smaps_pte_entry()
>> bails out before reaching smaps_account() and these pages are never counted
>> into mss->ksm. As a result /proc/<pid>/smaps and smaps_rollup report a KSM
>> value of 0 even though the region is fully merged.
>>
>> Count KSM-placed zero pages directly in smaps_pte_entry() using
>> is_ksm_zero_pte().
> Hm.
>
> We do expose "ksm_zero_pages" in /proc/<pid>/ksm_stat for calculating the KSM
> profit.
>
> Why would we want to expose it here as KSM pages?
>
> An application will notice the difference between "zeropage enabled vs.
> disabled" either way because we'll also not account zerpages towards e.g.,
> "Anonymous".
>
> So faking that something consumes memory when it actually doesn't consume memory
> is wrong?

Indeed. As Documentation/filesystems/proc.rst says, smaps shows the memory consumption of
each mapping and flags associated with it. KSM-placed zero pages shouldn't be accounted.