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

[Michal Hocko <mhocko@suse.com>]

On Tue 17-02-26 23:22:20, 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.

I believe you wanted to say "but never modified". Unless you map THP
through ptes you have simply do not have that information. Reading
zeroes might be just what your workload needs (e.g. large sparce data
structures).

> 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.

Let me clarify. I am not objecting the inefficiency. _If_ you need to
recognize zero content then there are no ways around. I have merely
mentioned that the overhead is not negligible for /proc/<pid>/smaps as
you suggested.

> - 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.

Completely agreed!

> 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.

While I agree with your first point I am not so sure about the second.
You can easily run the same workload with and without THP enabled and
compare the rss to learn about a typical internal fragmentation (there
are several layers of precision you can influence - only for process,
madvise...). This is a very crude estimate but it gives you some
picture. Is it convenient. Not at all but likely sufficient if you are
debugging a reproducible workload. 

So I would start by explaining why this crude approach is not really
feasible. You are talking about early-unmap. How exactly do you envision
this to be done? I mean finding zero pages is one thing but how do you
make any educated guess that that particular sparsely used page needs to
be broken down and partially unmapped. What kind of interface do you
want to use for that? MADV_FREE for all zero subranges?
-- 
Michal Hocko
SUSE Labs