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

[Kairui Song]

On Thu, Mar 26, 2026 at 4:02 PM Lorenzo Stoakes (Oracle) <ljs@xxxxxxxxxx> wrote:
>
> On Thu, Mar 26, 2026 at 08:03:34AM +0100, Michal Hocko wrote:
> > On Wed 25-03-26 19:05:47, Andrew Morton wrote:
> > > On Wed, 25 Mar 2026 14:06:37 -0700 Shakeel Butt <shakeel.butt@xxxxxxxxx> wrote:
> > >
> > > > We should unify both algorithms into a single code path.
> > >
> > > I'm here to ask the questions which others fear will sound dumb.
> >
> > Not dumb at all and recently discussed here https://lore.kernel.org/all/CAMgjq7AkYOtUL2HuZjBu5dJw=RTL7W2L1+zVv=SCOyHKYwc3AA@xxxxxxxxxxxxxx/T/#u
> >
> > > Is it indeed the plan to maintain both implementations?  I thought the
> > > long-term ambition was to knock MGLRU into shape and to drop the legacy LRU?
> >
> > Yes, but MGLRU is not there yet and with development pace last year or
> > so we are not much closer than at the time MGLRU has been merged
> > unfortunatelly.
>
> 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.