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

[Wenchao Hao <haowenchao22@gmail.com>]

On Wed, Feb 18, 2026 at 5:53 AM Kiryl Shutsemau <kas@kernel.org> wrote:
>
> On Tue, Feb 17, 2026 at 09:29:02PM +0100, David Hildenbrand (Arm) wrote:
> > On 2/17/26 16:22, Wenchao Hao wrote:
> > > On Sat, Feb 14, 2026 at 4:45 PM Wenchao Hao <haowenchao22@gmail.com> wrote:
> > > >
> > > > Add kernel command line option "count_zero_page" to track anonymous pages
> > > > have been allocated and mapped to userspace but zero-filled.
> > > >
> > > > 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@gmail.com/
> > >
> > > Sorry for the late reply. We are now on Chinese New Year holiday, so...
> > >
> > > The original goal of this patch is to measure memory waste from anonymous
> > > THPs - pages pre-allocated on fault but never accessed.
> > >
> > > On memory-sensitive devices like mobile phones, this helps us make better
> > > decisions about when and how to enable THP. I think this is useful for
> > > guiding THP policies, even as a debugging feature.
> > >
> > > Let me summarize the discussion so far:
> > > - Matthew Wilcox questioned the value and raised concerns fork but haven't
> > >    exec path
> > > - Michal Hocko criticized the inefficiency of scanning zero-filled pages.
> > > - Kiryl Shutsemau prefers a system-call-based interface.
> > > - David Hildenbrand acknowledged the value and suggested implementation
> > >    improvements.
> > > Please correct me if I missed or misrepresented anything.
> > >
> > > I suggest we first agree whether this functionality is useful for upstream,
> > > before discussing implementation details.
> > >
> > > Reasons why this should go upstream from me:
> > >
> > > - Anonymous THP can introduce real memory waste, but we currently have no
> > >    good way to measure it.
> > > - With accurate metrics, we can make better THP policy: disable for
> > >    low-utilization cases, or early-unmap to relieve memory pressure and so
> > >    on. This is especially valuable for mobile/embedded devices.
> > >
> > > Possible implementations:
> > >
> > > 1. A new smaps counter (default-off) to count zero-filled pages.
> > > 2. A new madvise command like MADV_GET_ZEROPAGE
> > > 3. A dedicated system call
> >
> > I understand Kiyls point about smaps providing too much information users
> > might not be interested in already. So sorting that out might provide a real
> > benefit to other users that are only interested in specific stats (e.g.,
> > Rss).
>
> You can also limit the range of virtual address space you want to look
> at.
>
> > Providing a system call where one can specify/filter in theory sounds like a
> > good idea. A syscall implies that one has to write a tool to obtain these
> > metrics.
> >
> > The nice thing about smaps/smaps_rollup is that it can be easily consumed on
> > any system while debugging.
> >
> > I wonder if there could be a way to achieve something similar with a file.
> > Likely not, but maybe someone reading along can surprise me :)
>
> I guess you can open a file write to it what you want to get and then
> read. It is awkward from shell to keep file descriptor around, but doable.
>

That approach doesn’t seem very elegant and could be rather complex.
In practice, we might need to analyze multiple processes simultaneously,
which would be quite difficult to implement.

> > Otherwise we'd have to go with a tool.
>
> A tool might be more ergonomic.
>
> To minimize friction, it would be nice to put the tool into util-linux
> (or whatever trendy Rust-rewrite called), so it would find its way to
> every machine. Eventually.
>

At the moment, we have two possible implementation approaches:

One is to extend smaps, with a dynamic toggle to count zero‑filled pages
only when explicitly enabled, so we avoid introducing unnecessary overhead
by default.
A potential downside of smaps is its relatively low information density, as
it may include data users are not interested in.
While in my view, the rich information from smaps is still very helpful for
memory analysis. For example, when a process shows large memory
fluctuations under certain scenarios, smaps snapshots can help us
investigate the root cause.

The other approach is to introduce a new system call, which could then be
packaged into a standard tool. This would allow higher information density
and filter out redundant data compared to smaps.

But so far we have been focusing on implementation details. I believe the
higher priority question is whether upstream actually needs this kind of
functionality.

I don’t want to waste community time and resources discussing something
the mainline does not consider valuable. I’d appreciate hearing everyone’s
thoughts on this.

Thanks.

> --
>   Kiryl Shutsemau / Kirill A. Shutemov