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

[Johannes Weiner <hannes@cmpxchg.org>]

Hello,

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,                           

We have run into this before as well. It's not super
rare. Applications do partial unmaps or protection changes with no
awareness for THPs. The issue is likely to stick around with legacy
software for some time.

Do note that all information is there if you know how to look for
it. But it is cumbersome and somewhat inconsistent, so I'm not opposed
to fixing it:

> > 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.                                                    
> >
> 
> ps -p $(pgrep -d, test) -o pid,comm,%mem,rss,vsz
>     PID COMMAND         %MEM   RSS    VSZ
>    9358 test             0.1 165220 166032
> 
> 
> MemTotal:       101606276 kB
> MemFree:        13172092 kB
> MemAvailable:   13569668 kB
> Buffers:            5352 kB
> Cached:          1169520 kB
> SwapCached:            0 kB
> Active:         84730404 kB
> Inactive:        1129792 kB
> Active(anon):   84730404 kB

This shows actually allocated anon+shmem.

> Inactive(anon):        0 kB
> Active(file):          0 kB
> Inactive(file):  1129792 kB
> Unevictable:        6192 kB
> Mlocked:              32 kB
> SwapTotal:       4194300 kB
> SwapFree:        4194300 kB
> Zswap:                 0 kB
> Zswapped:              0 kB
> Dirty:                24 kB
> Writeback:             0 kB
> AnonPages:        969280 kB

This shows anon *mapped*.

> Mapped:           308848 kB
> Shmem:             45076 kB

This shows that your (in)active anon *isn't* driven by shmem.

> KReclaimable:      96144 kB
> Slab:             269540 kB
> SReclaimable:      96144 kB
> SUnreclaim:       173396 kB
> KernelStack:       27584 kB
> PageTables:       187408 kB
> SecPageTables:         0 kB
> NFS_Unstable:          0 kB
> Bounce:                0 kB
> WritebackTmp:          0 kB
> CommitLimit:    54997436 kB
> Committed_AS:    6628776 kB
> VmallocTotal:   261087232 kB
> VmallocUsed:       38696 kB
> VmallocChunk:          0 kB
> Percpu:            42800 kB
> HardwareCorrupted:     0 kB
> AnonHugePages:    413696 kB

This shows anon pmd-mapped.

> ShmemHugePages:        0 kB
> ShmemPmdMapped:        0 kB
> FileHugePages:    172032 kB
> FilePmdMapped:     28672 kB

This shows both allocated huge pages and the pmd-mapped portion.

So you *can* work it out by looking at the LRU ((in)active) and
cross-checking the shmem position. But it is awkward, granted.

IMO if there is a case to be made, it's doing the same split we do for
file and shmem - AnonHugePages (allocated) and AnonPmdMapped.