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

[Kairui Song]

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

>
> > 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).

>
> > 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.