Re: [PATCH] mm/thp: expose deferred split folio memory usage in meminfo

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Fri, Jul 17, 2026 at 05:38:10PM +0800, liuye wrote:
>
> 在 2026/7/17 17:24, Ye Liu 写道:
> >
> > 在 2026/7/17 16:08, Lorenzo Stoakes (ARM) 写道:
> >> +cc Johannes
> >>
> >> On Fri, Jul 17, 2026 at 02:30:22PM +0800, Ye Liu wrote:
> >>> From: Ye Liu <liuye@kylinos.cn>
> >>>
> >>> Folios on the deferred split list hold physical memory that is
> >>> invisible in meminfo. When a THP becomes partially mapped, the
> >>> unmapped pages are removed from AnonPages but remain physically
> >>> allocated until the shrinker splits the folio. This creates a
> >>> memory accounting gap where used memory cannot be attributed to
> >>> any meminfo field.
> >> Is this really that much of an issue? You're not giving any use cases here.
> >>
> >> What real-world use case motivated this?
> >>
> > I have indeed encountered this situation in a customer environment,

And determined the cause so not sure what the issue is.

It must be quite a strange workload for it to be a meaningful amount.

> > but the environment is complex, and I cannot clearly explain why this memory
> > black hole occurs in that scenario.
> > However, I will provide an example to reproduce it below.
> > Use case: The system has 100GB of memory. A user-space program requests 80GB of memory.
> > For each 2MB block, only one page is retained, and the mapping of all other pages is unmapped,
> > while the process continues to run.
> > You'll find that in meminfo, MemFree: only 12GB remains,
> > but the process actually uses very little memory.
> > This creates a memory black hole situation.
> > Below is the test program I used, from AI.

Let me stop you there at AI-generated. Not interested.

As David said this exposes internal implementation details so it's a non-starter. NAK.

Thanks, Lorenzo