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

[Wenchao Hao]

On Mon, Feb 16, 2026 at 10:23 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> 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.
>
> Why are you trying to get this upstream when you admitted in an earlier
> email this is just for your internal use?
>

I see this as a debugging feature, not limited to internal use only.

Our real goal is to gain more precise visibility into how system memory is used.
A basic requirement is to measure the memory overhead caused by anonymous
hugepages that have been pre-allocated but never accessed.
With this information, we can implement various policies:
 - Allocate only 4K pages for applications that suffer severe memory waste from
   anonymous hugepages.
- Evaluate per-process hugepage waste during low system load and proactively
   split hugepages accordingly.

So I believe this debugging feature still provides value when merged upstream.
Currently, there is no effective way to account for memory waste from
pre-allocated
but unused anonymous hugepages, and this feature fills that gap. Or do you have
any suggestions about how to get this info?

> Why do you think that "unaccessed pages" are the only, or even the
> largest source of extra memory consumption?  The vast majority of files
> are never mmaped.
>

In my view, memory waste from anonymous hugepages is less acceptable than that
from file pages.

Although file pages may also be unmapped, a cache hit can still reduce
I/O overhead.
By contrast, pre-allocated anonymous hugepages that are never accessed represent
pure waste.

Furthermore, the total number of unmapped file pages can already be
estimated from
/proc/meminfo, so we can already apply policies to control file page waste.

>From my research, many memory-sensitive environments already apply
special policies
for file pages—for example, the RFC patch from vivo that manages
readahead file pages
separately:
https://lore.kernel.org/linux-mm/20250916072226.220426-1-liulei.rjpt@xxxxxxxx/

But file page waste is not the main point I want to focus on here.

Thanks.