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

["David Hildenbrand (Arm)" <david@kernel.org>]

On 11/12/26 14:03, Jose A. Perez de Azpillaga wrote:
> 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.

Ok. Because I would really be interested in real-life scenarios where it is a
problem.

It's only relevant for long-running parent+child combinations. For short-lived
children (e.g., fork+exec) it's irrelevant.

> 
>>
>> 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

That would be really interesting. I assume there are some cases where a simple
fork+exec would already add pages to the deferred split list even thought they
are briefly after fully mapped by the parent.

> 
>>>
>>> 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.

Ah, 512MiB of THPs, not 512MB THP, Yes, that makes sense.

[...]

>>
>> 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?
> 

As an alternative, could we also just look for the next page incrementally?

Like, start with offset 0. When we see that, move to offset 1, when we see that,
move to offset 2 ... and once we saw all pages that way, stop the walk.

I'd assume that, as long as VMAs don't get remapped, that should likely work in
most cases, right?

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

I'd be very interested in an efficient way to test if a folio is partially
mapped, and where the holes are.

Knowing about the holes could guide a targeted buddy-like folio split.

There was also the idea of letting folio_referenced() for that purpose, when we
area already doing an rmap walk.

-- 
Cheers,

David