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

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.

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

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.

-- 
Cheers,

David