This is version 3 of switching the THP shrinker to list_lru.

Changes in v3:
- dedicated lockdep_key for irqsafe deferred_split_lru.lock (syzbot)
- conditional list_lru ops in __folio_freeze_and_split_unmapped() (syzbot)
- annotate runs of inscrutable false, NULL, false function arguments (David)
- rename to folio_memcg_list_lru_alloc() (David)

Changes in v2:
- explicit rcu_read_lock() in __folio_freeze_and_split_unmapped() (Usama)
- split out list_lru prep bits (Dave)

The open-coded deferred split queue has issues. It's not NUMA-aware
(when cgroup is enabled), and it's more complicated in the callsites
interacting with it. Switching to list_lru fixes the NUMA problem and
streamlines things. It also simplifies planned shrinker work.

Patches 1-4 are cleanups and small refactors in list_lru code. They're
basically independent, but make the THP shrinker conversion easier.

Patch 5 extends the list_lru API to allow the caller to control the
locking scope. The THP shrinker has private state it needs to keep
synchronized with the LRU state.

Patch 6 extends the list_lru API with a convenience helper to do
list_lru head allocation (memcg_list_lru_alloc) when coming from a
folio. Anon THPs are instantiated in several places, and with the
folio reparenting patches pending, folio_memcg() access is now a more
delicate dance. This avoids having to replicate that dance everywhere.

Patch 7 finally switches the deferred_split_queue to list_lru.

Based on mm-unstable.

 include/linux/huge_mm.h    |   6 +-
 include/linux/list_lru.h   |  46 ++++++
 include/linux/memcontrol.h |   4 -
 include/linux/mmzone.h     |  12 --
 mm/huge_memory.c           | 342 ++++++++++++++-----------------------------
 mm/internal.h              |   2 +-
 mm/khugepaged.c            |   7 +
 mm/list_lru.c              | 196 ++++++++++++++++---------
 mm/memcontrol.c            |  12 +-
 mm/memory.c                |  52 ++++---
 mm/mm_init.c               |  15 --
 11 files changed, 323 insertions(+), 371 deletions(-)

Hi Joannes,

This is at v3 and you've not cc'd the majority of THP people:

MEMORY MANAGEMENT - THP (TRANSPARENT HUGE PAGE)
M:	Andrew Morton <akpm@linux-foundation.org>
M:	David Hildenbrand <david@kernel.org>
M:	Lorenzo Stoakes <ljs@kernel.org>            <--- (!)
R:	Zi Yan <ziy@nvidia.com>
R:	Baolin Wang <baolin.wang@linux.alibaba.com> <---
R:	Liam R. Howlett <Liam.Howlett@oracle.com>
R:	Nico Pache <npache@redhat.com>              <---
R:	Ryan Roberts <ryan.roberts@arm.com>         <---
R:	Dev Jain <dev.jain@arm.com>                 <---
R:	Barry Song <baohua@kernel.org>              <---
R:	Lance Yang <lance.yang@linux.dev>           <---

I'd assume it was an oversight but you're an mm sub-maintainer yourself so
I'm a little surprised...

Anyway could you please make sure to do that going forward?

I'd like to rely on lei's file-tracking stuff to catch cases like this, but
I just haven't got new mail tracking working properly in that environment
and it's really too slow.

It sucks to rely on people cc-ing but email development is what it is :)

Thanks, Lorenzo

On Wed, Mar 18, 2026 at 09:00:57PM +0000, Lorenzo Stoakes (Oracle) wrote:
> Hi Joannes,
> 
> This is at v3 and you've not cc'd the majority of THP people:
> 
> MEMORY MANAGEMENT - THP (TRANSPARENT HUGE PAGE)
> M:	Andrew Morton <akpm@linux-foundation.org>
> M:	David Hildenbrand <david@kernel.org>
> M:	Lorenzo Stoakes <ljs@kernel.org>            <--- (!)
> R:	Zi Yan <ziy@nvidia.com>
> R:	Baolin Wang <baolin.wang@linux.alibaba.com> <---
> R:	Liam R. Howlett <Liam.Howlett@oracle.com>
> R:	Nico Pache <npache@redhat.com>              <---
> R:	Ryan Roberts <ryan.roberts@arm.com>         <---
> R:	Dev Jain <dev.jain@arm.com>                 <---
> R:	Barry Song <baohua@kernel.org>              <---
> R:	Lance Yang <lance.yang@linux.dev>           <---
> 
> I'd assume it was an oversight but you're an mm sub-maintainer yourself so
> I'm a little surprised...
> 
> Anyway could you please make sure to do that going forward?
> 
> I'd like to rely on lei's file-tracking stuff to catch cases like this, but
> I just haven't got new mail tracking working properly in that environment
> and it's really too slow.
> 
> It sucks to rely on people cc-ing but email development is what it is :)
> 
> Thanks, Lorenzo

I apologize, there was no ill intent here at all. get_maintainers.pl
gave me 27 addresses for this series and I honestly thought that was
too aggrandizing and self-important for what these patches are lol.

So what you're looking at is a (poor) attempt at trimming down the CC
list based on who I had talked to about these patches at the THP
meeting and who I remember had worked on shrinkers & cgroups.

I can CC everybody going forward, not a problem. Personally I don't
mind getting CCd generously, but my understanding is that some people
do...

On Wed, Mar 18, 2026 at 06:31:14PM -0400, Johannes Weiner wrote:
> On Wed, Mar 18, 2026 at 09:00:57PM +0000, Lorenzo Stoakes (Oracle) wrote:
> > Hi Joannes,
> >
> > This is at v3 and you've not cc'd the majority of THP people:
> >
> > MEMORY MANAGEMENT - THP (TRANSPARENT HUGE PAGE)
> > M:	Andrew Morton <akpm@linux-foundation.org>
> > M:	David Hildenbrand <david@kernel.org>
> > M:	Lorenzo Stoakes <ljs@kernel.org>            <--- (!)
> > R:	Zi Yan <ziy@nvidia.com>
> > R:	Baolin Wang <baolin.wang@linux.alibaba.com> <---
> > R:	Liam R. Howlett <Liam.Howlett@oracle.com>
> > R:	Nico Pache <npache@redhat.com>              <---
> > R:	Ryan Roberts <ryan.roberts@arm.com>         <---
> > R:	Dev Jain <dev.jain@arm.com>                 <---
> > R:	Barry Song <baohua@kernel.org>              <---
> > R:	Lance Yang <lance.yang@linux.dev>           <---
> >
> > I'd assume it was an oversight but you're an mm sub-maintainer yourself so
> > I'm a little surprised...
> >
> > Anyway could you please make sure to do that going forward?
> >
> > I'd like to rely on lei's file-tracking stuff to catch cases like this, but
> > I just haven't got new mail tracking working properly in that environment
> > and it's really too slow.
> >
> > It sucks to rely on people cc-ing but email development is what it is :)
> >
> > Thanks, Lorenzo
>
> I apologize, there was no ill intent here at all. get_maintainers.pl
> gave me 27 addresses for this series and I honestly thought that was
> too aggrandizing and self-important for what these patches are lol.

Thanks, yeah email for development is a complete pain to be honest!

I wouldn't say that the cc list in any way would be perceived as
self-aggrandizing, I mean some of the trivial stuff I've sent to larger cc
lists :P

But I get your point, it's a kind of impossible balancing act :)

>
> So what you're looking at is a (poor) attempt at trimming down the CC
> list based on who I had talked to about these patches at the THP
> meeting and who I remember had worked on shrinkers & cgroups.
>
> I can CC everybody going forward, not a problem. Personally I don't
> mind getting CCd generously, but my understanding is that some people
> do...

Yeah I have often sent series where the list felt... egregiously huge, but
I _generally_ treat it as - people are used to getting tonnes of mail - so
some more shouldn't hurt.

I mean in [0] for example I really cringed at sending a 23 patch series
that is super super mm-centric and really just updating how we manage VMA
flags (trying to get away from system word size flags) - to a trillion
people.

TL;DR - anyway, I think get_maintainer.pl --nogit (and trim anyone who
isn't listed as a maintainer or reviewer) is the right balance to take -
maintainers with screwed up email set ups (*cough* naming no names
beginning with L and ending with orenzo) and reviewers who have signed up
for lots of mail I think are totally fine to always send to.

And of course +cc anybody else you feel appropriate.

The 'git' maintainers entries can absolutely be dropped though, unless
you're explicitly say radically changing something somebody contributed and
it makes sense to include them though all that's subjective!

Cheers, Lorenzo

[0]:https://lore.kernel.org/linux-mm/cover.1773846935.git.ljs@kernel.org/

> TL;DR - anyway, I think get_maintainer.pl --nogit (and trim anyone who
> isn't listed as a maintainer or reviewer) is the right balance to take -
> maintainers with screwed up email set ups (*cough* naming no names
> beginning with L and ending with orenzo) and reviewers who have signed up
> for lots of mail I think are totally fine to always send to.

On some simplistic changes (e.g., simple function rename) I sometimes
drop the Reviewers of subsystems because the simplistic changes are
mostly just as information to maintainers that there might be conflicts.

That helped in the past to reduce the CC lists on series that touch many
archs / subsystems.

-- 
Cheers,

David

On Thu, Mar 19, 2026 at 09:52:14AM +0100, David Hildenbrand (Arm) wrote:
> > TL;DR - anyway, I think get_maintainer.pl --nogit (and trim anyone who
> > isn't listed as a maintainer or reviewer) is the right balance to take -
> > maintainers with screwed up email set ups (*cough* naming no names
> > beginning with L and ending with orenzo) and reviewers who have signed up
> > for lots of mail I think are totally fine to always send to.
>
> On some simplistic changes (e.g., simple function rename) I sometimes
> drop the Reviewers of subsystems because the simplistic changes are
> mostly just as information to maintainers that there might be conflicts.

Yeah makes sense!

>
> That helped in the past to reduce the CC lists on series that touch many
> archs / subsystems.

It'd be nice if get_maintainer.pl could have some functionality to make all this
easier. But that sounds like self-volunteering a bit too much :P *cough*

>
> --
> Cheers,
>
> David

Cheers, Lorenzo