Re: [PATCH v1 2/2] mm/memory: add anonymous mTHP folios to deferred split list

[Johannes Weiner <hannes@cmpxchg.org>]

On Wed, Jul 29, 2026 at 02:38:53PM +0200, David Hildenbrand (Arm) wrote:
> On 7/8/26 19:52, Joanne Koong wrote:
> > On Wed, Jul 8, 2026 at 12:56 AM David Hildenbrand (Arm)
> > <david@kernel.org> wrote:
> >>
> >> On 7/7/26 22:17, Joanne Koong wrote:
> >>> Unlike for PMD-sized folios, an anonymous mTHP folio doesn't get added
> >>> to the deferred split list at fault or collapse time. As a result, a
> >>> fully mapped mTHP folio that is mostly zero-filled doesn't get split by
> >>> the deferred split shrinker when the system is under memory pressure.
> >>>
> >>> Add anonymous mTHP folios to the deferred split list so that if there's
> >>> memory pressure, a zero-filled mTHP can be split with its zero pages
> >>> remapped to the shared zero page and then reclaimed.
> >>>
> >>> To minimize overhead on the common order-0 fault path, the
> >>> deferred_split_folio() call is guarded by an inline folio_test_large()
> >>> check.
> >>>
> >>> Suggested-by: Usama Arif <usama.arif@linux.dev>
> >>> Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
> >>> ---
> >>>  mm/memory.c | 2 ++
> >>>  1 file changed, 2 insertions(+)
> >>>
> >>> diff --git a/mm/memory.c b/mm/memory.c
> >>> index 6637c5b13c9b..441d918e3dc0 100644
> >>> --- a/mm/memory.c
> >>> +++ b/mm/memory.c
> >>> @@ -5259,6 +5259,8 @@ void map_anon_folio_pte_nopf(struct folio *folio, pte_t *pte,
> >>>       folio_add_lru_vma(folio, vma);
> >>>       set_ptes(vma->vm_mm, addr, pte, entry, nr_pages);
> >>>       update_mmu_cache_range(NULL, vma, addr, pte, nr_pages);
> >>> +     if (folio_test_large(folio))
> >>> +             deferred_split_folio(folio, false);
> >>>  }
> >>>
> >>>  static void map_anon_folio_pte_pf(struct folio *folio, pte_t *pte,
> >>
> >> I had a session [1] at LSF/MM about having essentially all large anon folios
> >> part of the the deferred split queue.
> >>
> >> (1) I don't think this scales.
> >>
> >> (2) I suspect the shrinker should make smarter decisions of what to scan/reclaim
> >> first.
> >>
> >> I think this needs more proper thought.
> >>
> >> [1]
> >> https://docs.google.com/presentation/d/1RfKWCY1AMVns-WLn-QdAWbI2a-rA7fbFyh7XD1Wn5BY/edit?usp=sharing
> > 
> > Thanks for the link to the slides! Was there a conclusion from the
> > LSF/MM discussion about the future path forward for deferred splitting
> > or is that still being determined?
> 
> Sorry for the late reply. Unfortunately, it wasn't clear yet if we could
> reporpuse the LRU, whereby we would just naturally benefit from the LRU cache
> (soon) and only manage pages on a single list.
> 
> The concern was that we might end up scanning many items on the LRU to detect
> splitting candidates.
> 
> I am not 100% sure if that is a real problem.
> 
> As raised during the last THP cabal, my gut feeling is that Johannes might have
> an idea on how to improve things here.

I've been trying to reconstruct all the details we talked about at
LSFMM ;)

Going over this again, I still have to conclude using the anon LRU for
splitting is not a good idea. Let me try to lay it out:

(1) The anon LRU isn't scanned at all when there is no swap. This is
    fixable, but requires some re-architecting of the vmscan stack.

(2) With a mix of basepages and THPs, there could indeed be a lot of
    basepages ahead of underused THPs. That means swapping before
    getting to space that is much cheaper to reclaim.

    The current setup isn't perfect in that regard, as the shrinker
    runs simultaneously as the LRU. But it's making guaranteed forward
    progress through the THPs, even as the first LRU pages are scanned.

(3) The anon LRU has folio lifetime, but the splitqueue is one-shot:
    we scan each THP once, and then it's either split and dropped, or
    found full and dropped. That THP never needs to be revisited. The
    queue actually empties as the workload establishes itself.

    The anon LRU ~ splitqueue argument is only true around startup.

    If we used the anon LRU, we'd need per-page state to avoid repeat
    underused checks. And we need external state to not scan the anon
    LRU at all if there are no new THPs (and no swap). And if that's
    just a counter for "new, not yet scanned THPs", a single fault
    will cause you to walk the entire anon LRU before you get to it.

(4) The anon LRU is driven based on the cost of swap and observed
    refaults. These metrics are inherently bad modulators for scanning
    underused THP space.

    Using the anon LRU for splits means that if anon scanning slows
    down and we lean more on the file cache, we'd also slow down the
    search for unused THP space. This is undesirable. File cache is
    still more valuable than uninitialized anonymous memory:

                    | anon | file | uTHP |
    ----------------+--------------------+
    cost to reclaim |    1 |    0 |    0 |
    ----------------+--------------------+
    cost to refault |    1 |    1 |    0 |

    We're thinking anon LRU because those splittable, potentially
    underused THPs happen to be anon. But anon user data that needs to
    be swapped out is an inherently different class of reclaim targets
    than the uninitialized space *between* such anon user data.

    We really want uTHP -> clean cache -> swap reclaim ordering.

    Classic LRU takes this even further. Because of how the page cache
    grows endlessly compared to heap memory, classic will scan *only*
    the file LRU until those pages start refaulting. Using the anon
    LRU would get us a clean cache -> swap / uTHP ordering.

So I think reusing the anon LRU is flawed. It's fundamentally
different needles in fundamentally different haystacks.

If we can agree on that, then the lock contention problem has a
different scope as well: it's a simple optimization issue, not a
fundamental data structure arrangement issue.

If I understand you correctly, the concern is that people will enable
all manner of mTHP orders, and 99% of the anon faults, including all
the order-3, order-4 pagelets, will go through the list_lru lock on
fault, with no batching.

I do think that's valid, but how concrete is that right now? Is anyone
actually doing that? I would have some concerns purely from a
servability POV: the page allocator, watermarking, compaction etc. are
still a bottle neck for high rates of lower orders, as we've been
noticing with the page cache and the optimistic vmalloc higher orders.

The concrete proposal I've seen from several places was much simpler:
I have ARM 64k basepages and I want 2M THPs.

But in that case, the splitqueue looks no different than on x86 today.

My take is that we should add mTHPs to the split queue as-is. Deal
with the locking/batching concern when real usecases say we should.