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

David Hildenbrand (Arm)
2026-03-26T13:42:45Z

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@kernel.org> 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@linux-foundation.org>
>
> Well Andrew is Andrew :)
>
> M: Axel Rasmussen <axelrasmussen@google.com>
>
> 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@tencent.com/
> recently for example, but not much in 2025 afaict.
>
> M: Yuanchu Xie <yuanchu@google.com>
>
> 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@google.com>
>
> 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@kvack.org
> 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