Re: [RFC PATCH 0/2] mm/huge_memory: find partially mapped shared folios with NO_PAGE_MAPCOUNT

["Jose A. Perez de Azpillaga" <azpijr@gmail.com>]

On 11/12/26 1:46 PM, David Hildenbrand (Arm) wrote:
> On 11/11/26 12:31, Jose A. Perez de Azpillaga wrote:
>> With CONFIG_NO_PAGE_MAPCOUNT, an anon large folio mapped by several MMs
>> isn't seen as partially mapped while its mapcount stays at or above the
>> number of pages. If parent and child zap the same half of a THP after
>> fork(), that half is mapped by nobody, the folio is never queued for
>> deferred split, and the memory stays allocated until every mapper is
>> gone.
> 
> If you follow the history on this, in e.g., some raised in my talk
> 
> https://share.daveh.de/s/bQsDpD7xigJ6wD8/download?path=&files=LSF_MM%2726_+Deferred_folio_splitting.pdf
> 
> There are a lot of questions around this.
> 
> In particular
> 
> (a) Is it really relevant in practice. The only way you can trigger this if a
> folio becomes partially mapped *after* fork (by parent and child unmapping the
> same pages), and the child stays alive. Once the child is gone, the folio is
> only mapped by one process (e.g., child quit), the folio is properly detected as
> partially mapped.

I don't have any relevant evidence in practice. found it by just reading
and testing in qemu. that is why I sent it as RFC.

> 
> So you need a long-running parent+child, and have them both do questionable things.
> 
> (b) What is the overhead from having way too many folios in the deferred split list.
> 

I don't know yet. I only measured the walk in a TCG guest, nothing on
how long the list gets

>>
>> Patch 1 moves the split_underused_thp check out of
>> deferred_split_folio(). Patch 2 queues such folios as candidates and has
>> the shrinker walk the rmap to see which pages are still mapped.
>>
>> 512 MB of THPs with the same half zapped by every mapper, memory freed
>> by the shrinker:
>>
>>                                 before    after
>>   2M,  2 processes                0 MB   252 MB
>>   2M,  3 processes                0 MB   237 MB
>>   2M,  2 children + parent PMD    0 MB   244 MB
>>   64K, 2 processes                0 MB   252 MB
>>   64K, 3 processes                0 MB   252 MB
>>
> 
> Again, we can create nice scenarios that are likely not relevant in practice
> (such as 512 MB THPs, lol), but so far I doubted that this is relevant in practice.

that's 512 MB in total, not the folio size. maybe I should have
clarified it.

> 
> Do we have any evidence that real applications run into that and it's a problem
> for them?
> 
> The memory is charged to these processes and swapout etc. would still work.
> 
>> With patch 2 the shrinker reads shrink_underused itself, so folios
>> queued for the underused check aren't split anymore once it's turned
>> off.
>>
>> David suggested a check from the shrinker for the opposite case in [1],
>> folios marked partially mapped by a PTE by PTE unmap. The walk in patch 2
>> could clear the flag there too, this series doesn't do it.
>>
>> Questions:
>>
>> - Is an rmap walk from the shrinker fine for this? Every CoW of a page
>>   in a shared PTE-mapped folio queues a candidate, and so does the last
>>   PMD mapper when it splits its PMD.
> 
> You are asking the same question I asked in my LSF/MM session :)
> 
> I don't have a good answer to that, especially, once large folios (smaller than
> most THPs) come into play. Like 64k folios on a 4k kernel.
> 
>>
>> - The walk needs one bit per page, which is too much for the stack with
>>   64K pages, so I used a static bitmap under a mutex. That serializes
>>   the walks of all nodes and memcgs, and the mutex is taken with the
>>   folio locked. Where should the bitmap live?
> 
> Maybe one could track it a bit broader? "any page in this set of 16 pages is
> present". Reclaiming a single 4k page from a 2M folios is barely worth it.
> 

yes, that works. maybe with the group size scaled to the folio, so the
map is one long on the stack and 64K folio still gets one bit per page?

however, maybe if I don't have real evidence, better drop it?

-- 
cheers,
jose a. p-a