Re: [LSF/MM/BPF TOPIC] Towards Unified and Extensible Memory Reclaim (reclaim_ext)

[David Hildenbrand (Arm)]

On 3/26/26 14:13, Lorenzo Stoakes (Oracle) wrote:
> On Thu, Mar 26, 2026 at 08:37:06PM +0800, Kairui Song wrote:
>> On Thu, Mar 26, 2026 at 4:02 PM Lorenzo Stoakes (Oracle) <ljs@xxxxxxxxxx> wrote:
>>>
>>>
>>> I'm quite concerned about maintainership, as it seems the MGLRU maintainers have
>>> not been all that active, and the MGLRU to me at least is currently a black box.
>>>
>>> I'm not the only one who's raised this (see [0]).
>>>
>>> That'd very much have to be resolved and the community reassured that MGLRU is
>>> _actively_ maintained before we could even contemplate it replacing the
>>> 'classic' reclaim approach IMO.
>>>
>>> I hope that Kairu, Barry, Zicheng and others who are interested int it resolve
>>> this, however!
>>
>> Hi everyone,
>>
>> Right, I think we are starting to make good progress on improving
>> MGLRU recently. For the last few years we already have some commits
>> stashed downstream to enable that on our fleet, most of my effort in
>> upstream is spent on other parts like SWAP, really looking forward to
>> making MGLRU better upstreamly.
>>
>> Yesterday I was still discussing with CachyOS folks about their usage
>> while working on that series for MGLRU cleanup and dirty flush
>> optimization, and got some nice feedback later from their chat server
>> that MGLRU's TTL resolved their thrashing issue very well. With
>> classic LRU they needed a le9 patch downtreamly.
>>
>> For many other typical workloads under stress, MGLRU performs
>> significantly better too (e.g. database, build kernel could be more
>> than twice as fast), it would be a huge loss to leave it unmaintained.
>>
>> Barry also provided some really helpful ideas about MGLRU like
>> readahead handling. We are also seeing other vendors and people
>> contributing to MGLRU like Leno and Baolin recently. Things are
>> looking promising.
> 
> Guys, can I please make a plea then for you guys to AT LEAST become
> reviewers in MAINTAINERS please:
> 
> MEMORY MANAGEMENT - MGLRU (MULTI-GEN LRU)
> M:	Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> 
> Well Andrew is Andrew :)
> 
> M:	Axel Rasmussen <axelrasmussen@xxxxxxxxxx>
> 
> git log mm/vmscan.c has 0 results.
> 
> Axel has however engaged in discussion on
> https://lore.kernel.org/linux-mm/20260318-mglru-reclaim-v1-0-2c46f9eb0508@xxxxxxxxxxx/
> recently for example, but not much in 2025 afaict.
> 
> M:	Yuanchu Xie <yuanchu@xxxxxxxxxx>
> 
> git log mm/vmscan.c shows 1 result from August 13th 2024.
> 
> Yuanchu has engaged in some MGLRU discussion also recently, here and there.
> 
> R:	Wei Xu <weixugc@xxxxxxxxxx>
> 
> git log mm/vmscan.c shows 2 results from October 2024.
> 
> Wei doesn't look to have engaged in discussion on MGLRU recently.
> 
> L:	linux-mm@xxxxxxxxx
> S:	Maintained
> W:	http://www.linux-mm.org
> T:	git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> F:	Documentation/admin-guide/mm/multigen_lru.rst
> F:	Documentation/mm/multigen_lru.rst
> F:	include/linux/mm_inline.h
> F:	include/linux/mmzone.h
> F:	mm/swap.c
> F:	mm/vmscan.c
> F:	mm/workingset.c
> 
> It doesn't really feel like MGLRU is currently maintained at all, quite
> honestly.
> 
> So I think we need people to step up here.


Ans some serious cleanup of the entry to reflect who is actually
involved nowadays, if at all.

Master of MAINTAINER updates, I assume you'll take care of that?

-- 
Cheers,

David