Re: [PATCH RFC 00/32] mm/mglru: MGLRU-FG and refault distance support

[Joanne Koong]

On Tue, Jul 21, 2026 at 9:23 PM Kairui Song <ryncsn@xxxxxxxxx> wrote:
>
> Joanne Koong <joannelkoong@xxxxxxxxx> 于 2026年7月22日周三 08:03写道：
> >
> > On Fri, May 1, 2026 at 2:03 PM Kairui Song via B4 Relay
> > <devnull+kasong.tencent.com@xxxxxxxxxx> wrote:
> > >
> > > This is an RFC following the idea proposed as LSFMMBPF topic [1] this
> > > year for demonstrating the design and improvements, sending it out so it
> > > can be discussed better before or after the event. It's stable and
> > > performing well, but obviously, it's too long for review, so I plan to
> > > send these out step by step if we are OK with the basic ideas here.
> >
> > Hi Kairui,
> >
> > Could you give an update on what your status and plans are for this
> > series? Are you still planning to send this out in independent chunks,
> > and if so, do you have a sense of the ordering you're thinking of?
>
> Hi Joanne,
>
> Thanks for asking!
>
> Yes, I think I will send an update next week as a new series. There
> are a few other MGLRU related things going on recently, so I spent a
> little more time on swap queue (which is quite important to solve the
> allocation issue for layered swap and multiple series may get blocked
> by that) and other patches. While I've just setup a new test
> environment and suite for better MGLRU testing on both server and
> android. I'm also collecting more test cases from others, and
> comparing performance against other reclaim policies like ZFS's ARC.
>
> The code didn't change much, still appliable on 7.2, and I'm just
> tuning the params in it to fit more workload better and some micro
> optimization. Testing is the hardest part for this :)
>
> Latest tree is available here:
> https://github.com/ryncsn/linux/tree/b4/mglru-fg

Awesome, thanks for the update! I'm also happy to help with any
testing that would be useful to you :)

As part of the work following up on the LSF reclaim discussion, I'm
planning to separate out the classic LRU and MGLRU implementations
into their own files. I think this will conflict quite a bit with the
changes in your series here though, so I'm planning to wait until your
flag format and MGLRU-FG changes have landed to proceed with that.

>
> >
> > > Worth noting that the design is still not finalized yet, the tier and
> > > refault calculation can still be better adjusted, and with more
> > > benchmarking and testing. This is rebased on top of the current
> > > mm-unstable as it is supposed to work on top of another series which is
> > > currently there [4].
> > >
> > > With this series, I'm seeing an obviously performance gain for tests
> > > like GET/SCAN with LevelDB (which is borrowed from Tal's paper [2])
> > > and MongoDB with TPCC [3] or YCSB [4]:
> > >
> > > GET/SCAN LevelDB [2]:
> > > Classical LRU: throughput_avg: 993.64 Ops/s
> >
> > If I'm understanding it correctly (and please correct me here if not
> > :)), the changes in patch 22 ("mm/workingset: simplify and use a more
> > intuitive model") for calculating the refault distance would also
> > affect classical LRU - did you also see any differences in performance
> > for Classical LRU before vs. after?
>
> And I posted a similar (but less competent) result for CLRU previously:
> https://lwn.net/ml/linux-kernel/20230920190244.16839-2-ryncsn@xxxxxxxxx/
>
> Yes I did a long term test for that across a few weeks, Classical LRU
> seems also worked better, however this is quite long time ago, based
> on 6.9, and tested on top of that older email, so I can't guarteen how
> it looks nowadays, should be fine I think:
>                         Before            After
>                         99b80ac45f7e      dc6364e0a90c
> mysql                   7461.17 qps       7587.36 qps
> (2G Mem, SSD SWAP)                        (+1.6%)
> mysql                   89915.23 qps      90204.59 qps
> (10G Mem, SSD SWAP)                       (+0.3%)
> mysql                   66962.37 qps      67186.73 qps
> (2G Mem, ZRAM SWAP)                       (+0.3%)
> mysql                   94720.35 qps      95135.87 qps
> (10G Mem, ZRAM SWAP)                      (+0.4%)
> mysql                   100694.54 qps     101018.13 qps
> (24G Mem, no SWAP)                        (+0.3%)
> fio                     6707.12 iops      6769.88 iops
> (16G Ramdisk, zipf:1.2)                   (+0.9%)
> fio                     1784.00 iops      1786.88 iops
> (16G Ramdisk, random)                     (+0.2%)
> memtier                 79199.06 ops/s    79595.91 ops/s
> (6G Mem, ZRAM)                            (+0.5%)
> build-linux-kernel      1766.03s          1764.74s
> (make -j32)                               (+0.1%)
>
> The gain was mostly from removing the workingset_activation, but the
> overhead of that function was reduced by a lot since 6.9 so nowaday
> test may not see any gain.
>
> My plan is ignore the second part (refault distance) in next update,
> so it can be reviewed easier and won't effect CLRU. It contributes
> little to scan resistance related jobs, none of the benchmark included
> in this RFC's cover letter benefit much from it. In this RFC, the
> refault distance unification is more like a demonstration that it
> could work and improve working set shift or significant over commit
> usage performance for MGLRU, like the file scan test in cache_ext's
> test repo (result not included here, but it does performance better).

That sounds great, thanks for the context.

>
> >
> > > MGLRU before:  throughput_avg: 951.12 Ops/s
> > > MGLRU after:   throughput_avg: 1344.72 Ops/s (+41% faster)
> >
> > The numbers look awesome! Do you know how much of that is attributed
> > to the MGLRU-FG changes vs the refault distance improvements?
>
> For this particular test, >90% of the performance gain is from
> MGLRU-FG, the refault distance part contributes very little.
>
> > > This series basically composed of three parts:
> > >
> > > 1) Make the MGLRU be frequency guided and rework MGLRU's flag format
> > >    to shrink the bit usage. The format rework and MGLRU-FG design is
> > >    strongly bound togther with 2) below.
> >
> > Could you say more about what binds the flag format rework to the
> > frequency-guided changes? In my reading of it, the patches for the
> > flag reformat work (encoding refs as a single int with
> > PG_referenced/PG_workingset as the low bits), the addition of the new
> > generic LRU-refs API, converting all workingset / referenced flag
> > users to this new API, and then deleting the
> > PG_referenced/PG_workingset page flags seem all valuable and
> > non-controversial on their own. Would it be feasible to have this
> > first as its own standalone series, with the patches that change
> > reclaim behavior (MGLRU-FG, refault distance) separated out into
> > follow-on series?
>
> Yes, exactly. I will drop the flags unification part first, it's not
> mandatory, just to show we will be able to redefine the flags and make
> MGLRU-FG's refs tracking calculations much simpler. Without that, many
> strange bit shift is needed for every MGLRU-FG refs operation, but it
> actually won't hurt anything (just extra 5 - 10 CPU cycles per
> operation maybe), and the flag format looks a bit ugly.

Gotcha. Can I ask what speaks against having the flags unification
work ordered first, with the MGLRU-FG patches based on top of that and
submitted in parallel as a separate series? It seems like the two
could be reviewed upstream concurrently, and I think that would make
the MGLRU-FG series easier to review with it on top of the flags
cleanup, and freeing the two page flags seems like a sweet win on its
own :) Is your concern that the FG series would then be gated on the
flag series landing and you anticipate that the flag series would take
longer to land than the FG series?

Thanks,
Joanne