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

From: David Hildenbrand (Arm)

Date: Fri Jul 17 2026 - 06:32:01 EST


On 7/17/26 11:54, Ye Liu wrote:
>
>
> 在 2026/7/17 17:48, Lorenzo Stoakes (ARM) 写道:
>> On Fri, Jul 17, 2026 at 11:33:05AM +0200, David Hildenbrand (Arm) wrote:
>>>
>>> Don't expose it to user space.
>>
>> Yeah please stop.
>>
>> We don't want this change, it exposes internal implementation details. It's a
>> no.
>>
>> Next time send an RFC or a discussion thread.
>>
> Yes, sending an RFC would be more appropriate.
>
> I'd also like to ask if it's possible to implement this in
> `/sys/kernel/debug/deferred_split_pages`, or are you completely against querying this statistic?

It's not pages. It's folios.

You don't know how much memory is there to reclaim. You don't know if it can
even be reclaimed.

You don't even know if there can be any memory reclaimed *at all*, because there
are scenarios where we add folios that are actually *not* partially mapped today.

You don't even know the relationship to memcgs.

>
> How can we quickly identify this situation?
> I believe some people will still be confused: where did the memory go?

Just like other caches that are shrunk on memory pressure.

We do have a "split_deferred" and a "nr_anon_partially_mapped" counter in
"/sys/kernel/mm/transparent_hugepage/hugepages-2048kB/", maybe that helps.

--
Cheers,

David