Re: [PATCH] mm: Add AnonZero accounting for zero-filled anonymous pages
From: David Hildenbrand (Arm)
Date: Mon Feb 16 2026 - 11:56:24 EST
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@xxxxxxxxxxxxx> 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.
All we want are per-process stats. What am I missing?
KSM could deduplicate them, the deferred shrinker could remove them. Unless both mechanisms are not desired or are ineffective for another reason (e.g., page pinning).
--
Cheers,
David