Re: [PATCH] mm: Add AnonZero accounting for zero-filled anonymous pages

[David Hildenbrand (Arm)]

On 2/16/26 16:10, Wenchao Hao wrote:
> On Mon, Feb 16, 2026 at 8:15 PM David Hildenbrand (Arm)
> <david@xxxxxxxxxx> wrote:
> > On 2/14/26 09:45, Wenchao Hao wrote:
> > > Add kernel command line option "count_zero_page" to track anonymous pages
> > > have been allocated and mapped to userspace but zero-filled.
> >
> > "count_zero_page" is rather sub-optimal parameter name. "anonzero_in_smaps" or sth like that?
> Your naming suggestion is indeed better than mine. If this patch is still needed
> for further development, I will modify it according to your advice.
>
> > Still wondering if there could be a better way to enable this dynamically.
> >
> > In particular, not using a core parameter.
> >
> > If you use a module parameter, you can just set on the cmdline
> >
> >          proc.anonzero_in_smaps=1
> >
> > And dynamically set/observe it in
> >
> >          /sys/module/proc/parameters/anonzero_in_smaps
> Regarding the use of module parameters versus core_param, I think
> either approach is ok.
> Currently, the core_param I'm using also supports two modification methods:
>
> 1. Command line parameter: count_zero_page=Y
> 2. After system boot, view or modify it via
> /sys/module/kernel/parameters/count_zero_page
>
> It is true that this modification would be more appropriately placed
> in the proc module,
> which aligns with your earlier suggestion.
>
> If there is a possibility of further iteration on this change, I will
> move it to the proc module instead
> of using a core_param
>
> > > This feature is mainly used to debug large folio mechanism, which
> > > pre-allocates and map more pages than actually needed, leading to memory
> > > waste from unaccessed pages.
> > >
> > > Export the result in /proc/pid/smaps as "AnonZero" field.
> > >
> > > Link: https://lore.kernel.org/linux-mm/20260210043456.2137482-1-haowenchao22@xxxxxxxxx/
> > > Signed-off-by: Wenchao Hao <haowenchao22@xxxxxxxxx>
> > > ---
> > >    Documentation/filesystems/proc.rst |  5 +++++
> > >    fs/proc/task_mmu.c                 | 10 ++++++++++
> > >    2 files changed, 15 insertions(+)
> > >
> > > diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst
> > > index b0c0d1b45b99..573c8b015e39 100644
> > > --- a/Documentation/filesystems/proc.rst
> > > +++ b/Documentation/filesystems/proc.rst
> > > @@ -545,6 +545,11 @@ replaced by copy-on-write) part of the underlying shmem object out on swap.
> > >    does not take into account swapped out page of underlying shmem objects.
> > >    "Locked" indicates whether the mapping is locked in memory or not.
> > >
> > > +"AnonZero" shows the size of anonymous pages that have never been accessed
> > > +after mapping, and it can reflect the memory waste caused by huge pages.
> >
> > That's not correct. They could be read/written, but with zeroes.
> >
> > > +Implemented by scanning the size of zero-filled pages of the VMA. It
> > > +is default disabled, and enabled via cmdline param "count_zero_page=true".
> >
> > Probably best to keep it simpler:
> >
> > "AnonZero" shows the size of anonymous pages that contain zeroes. Zero-filled
> > pages can indicate memory waste caused by memory-overallocation with (m)THPs.
> > Availability is controlled through XYZ.
> As with your earlier suggestion, if this change is to be iterated on
> further, I will update it according
> to your suggestion.

Let's wait first for other opinions. Willy doesn't seem to like it if 
there is no use case besides for limited experiments where you could 
just use the OOT patch, possibly.

--
Cheers,

David