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

["Vlastimil Babka (SUSE)" <vbabka@kernel.org>]

On 7/17/26 11:31, Ye Liu wrote:
> 在 2026/7/17 16:37, David Hildenbrand (Arm) 写道:
>> On 7/17/26 08:30, 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.
>>>
>>> Add NR_DEFERRED_SPLIT_PAGES to track the total memory consumed by
>>> folios currently on the deferred_split_lru, updated via
>>> mod_node_page_state() at all enqueue/dequeue points. The new field
>>> DeferredSplitPages is visible in /proc/meminfo, /proc/vmstat, and
>>> per-node /sys/devices/system/node/node*/meminfo.
>>>
>> 
>> Oh no.
>> 
>> This is really exposing a current implementation detail where we have this
>> information easily available in a way that we will not be able to change that
>> implementation later.
>> 
> 
> Yes, `/proc/meminfo` is a user-space ABI.                                
> Adding it there means you can't change the semantics,                    
> and the field will become unmaintainable, yet you can't delete it either.
> But I think this information is still necessary.                         
> Where would be a better place to put it?                                 

I once added KReclaimable to /proc/meminfo, its value used to be
SReclaimable plus ION allocator (I think), but that one was later removed so
it's now equivalent and I regret adding it and it stays there.

If the deferred split folios are just waiting for a memory pressure kick a
shrinker to reclaim them, the KReclaimable counter could however be a
sensible fit and wouldn't need adding a new user-visible output.

However I assume there's tradeoff with having to track this (complexity,
overhead) and possibly overhead of reading /proc/meminfo so it's not
clear-cut. Just pointing it out as a possibility.