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

[Michal Hocko <mhocko@suse.com>]

On Mon 16-02-26 23:59:50, Wenchao Hao wrote:
> On Mon, Feb 16, 2026 at 7:58 PM Kiryl Shutsemau <kirill@shutemov.name> wrote:
> >
> > On Mon, Feb 16, 2026 at 12:45:13PM +0100, David Hildenbrand (Arm) wrote:
> > > On 2/16/26 12:34, Kiryl Shutsemau wrote:
> > > > On Sat, Feb 14, 2026 at 04:45:14PM +0800, 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.
> > > > >
> > > > > 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.
> > > >
> > > > I expect it to slowdown /proc/pid/smaps read substantially. I don't
> > > > think this line in smaps worth it.
> > > >
> > >
> > > That's why it's enabled through a command line parameter.
> >
> > One users want the stat and all users on the machine pay the price?
> > That's a poor trade off.
> >
> > In general, smaps scales poorly. It collects a lot of stats and most of
> > them are ignored by user. We need something like statx(2) where user can
> > declare what he is interested in, so kernel won't waste cycles.
> >
> 
> I initially considered two approaches:
> 
> First, exposing the needed information via smaps. This does incur some
> performance cost but is the simplest to implement. The new feature can be
> dynamically toggled via a command-line parameter. When disabled, the
> overhead is negligible—only a minor if check, which is insignificant compared
> to the full smaps cost.

You are comparing content of all anon pages, aren't you? Depending on
the content this can add a lot of overhead.

> Second, adding a new system call or extending madvise with a new command
> like MADV_GET_ZEROANON. Userspace tools can then use it to measure
> memory waste from zero-filled anonymous huge pages.

MADV_GET_ZEROPAGE would make more sense to me. But a more fundamental
question is whether this metric is really what you want long term.
Kernel can do all sorts of optimizations behind userspace back - e.g.
map shared zero page - so just learning that a process has a lot of
pages filled up with zeroes doesn't tell you all that much. Or does it?

Also think about what do you do with those numbers. Any action performed
later is inherently racy. Aren't you really looking for something like
MADV_COMPACT or maybe even MADV_COMPRESS?
-- 
Michal Hocko
SUSE Labs