Re: LSF/MM/BPF TOPIC] Deferred folio splitting: extend or remove/replace?

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

On 2/23/26 12:26, David Hildenbrand (Arm) wrote:
> Hi,
> 
> the "deferred" folio splitting mechanism was originally introduced to reclaim
> memory from partially-mapped anonymous THPs under memory pressure. Partially-
> mapped anonymous folios (often) guarantee that at least some memory can get
> reclaimed easily.
> 
> Ever since, we extended it to also handle smaller large folios (mTHPs),
> but also to scan for mostly-zero-filled mTHPs that can be reclaimed by replacing
> them with the shared zeropage.
> 
> Nowadays, each and every (m)THP we allocate gets added to the deferred split
> list as default, as "split_underused_thp = true", which is rather suboptimal.
> 
> Historically, handling deferred splits has been rather complicated and error-prone.
> 
> So I've been wondering whether that complexity still warranted. Could we instead
> just let LRU scanning deal with that and get rid of the shrinker?
> 
> Or could a shrinker instead use existing LRU lists?
> 
> 
> We could flag folios for being
> * Partially mapped (which we already do)
> * Possibly over-allocated (unscanned for zero since added)
> 
> To prioritize processing them.
> 
> One of my motivations for looking into this topic is that with
> CONFIG_NO_PAGE_MAPCOUNT, we can sometimes not reliably detect "partially mapped"
> folios and only know that a folio "might be partially mapped". To figure out
> whether it is actually partially-mapped, we have to walk the RMAP.
> 
> While I could extend the deferred splitting mechanism to handle such partially-
> mapped folios as well, it would imply taking the deferred split locks more
> frequently when unmapping pages ... not having to mess with another list might
> simplify things.
> 

Slides at:
https://share.daveh.de/s/bQsDpD7xigJ6wD8/download?path=&files=LSF_MM%2726_%20Deferred_folio_splitting.pdf

-- 
Cheers,

David