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

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

On 7/29/26 17:04, Johannes Weiner wrote:
> 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:
>>>
>>> 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:

Heh, and I am not convinced that maintaining or extending the deferred shrinking
code is future proof.

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

Yes, that should be fixable.

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

The shrinker would obviously remain and scan the list for candidates. We might
want to remember how man / if any such entries we have on the list.

I'd imagine that reclaim can handle that as well.

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

Remembering "not yet scanned" through a pageflag (for large folios) is indeed
very easy.

I don't quite understand the "a single fault", can you elaborate?

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

I am not sure I follow. I say that we keep the deferred shrinker, but
instead of maintaining our own ugly mess of a list, we scan the anon folio
list.

So the LRU algorithm will just mostly be kept as is.

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

I don't agree yet :) But maybe I am missing something important.

Note that the "simple optimization issue" is not so simple once you
realize what kind of a pain the batched LRU already creates us when it
comes to predicting the number of expected folio references.

It's a pain I don't want to extend to other areas.

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

Yes. See Barry's LRU cache change I linked as reply to Usama who is looking for
example at a system that mostly just uses order-2 anon folios.

> 
> I do think that's valid, but how concrete is that right now? Is anyone
> actually doing that? 

Yes, thus Barry's patch :)

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

That one is easy, I don't have a problem with that.

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

And that's where I disagree when it comes to small folios. Batching what we know
from LRU cache is a pain we are not going to replicate elsewhere.

-- 
Cheers,

David