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

[Michal Hocko <mhocko@suse.com>]

On Mon 16-02-26 17:56:12, David Hildenbrand wrote:
> On 2/16/26 17:42, Michal Hocko wrote:
> > 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:
> > > > 
> > > > 
> > > > 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?
> 
> If a sysadmin wants to see where THP hurt (zero-filled pages), surely
> MADV_GET_ZEROPAGE is the wrong (ugly) interface.

The question is whether sysadmin should really ask questions like that.
Without a deeper understanding of the workload the answer could be
misleading at best, no matter what interface is available.

If you know and understand the workload you already know that THP is not
a good fit and you do not need to ask about that. If you want to
understand whether your particular workload has a big internal
fragmentation due to THPs then MADV_GET_ZEROPAGE sounds like a
reasonable fit to me.

From a sysadmin POV you care about the overall memory consuption, right?
And for that I believe you need some sort of high level compression or
similar interface.

-- 
Michal Hocko
SUSE Labs