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

在 2026/7/17 18:29, Johannes Weiner 写道:
> 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 <[email protected]>
>>>>>
>>>>> 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.
Yes, R&D personnel may be able to draw conclusions through analysis, 
but this is indeed not very intuitive for operations and maintenance personnel.
> 
> 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.

This also adds a new field, which doesn't seem to be welcomed.

-- 
Thanks,
Ye Liu