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

[Joanne Koong]

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?

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

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

>
> MongoDB YCSB workloadb (MGLRU):
> Before: 82127.65 ops/sec
> After:  95933.99 ops/sec (+16.8%)
>
> Build kernel test (MGLRU):
> Before: refault_file: 259681   refault_anon: 3006202  real: 1m49.005s
> After:  refault_file: 201472   refault_anon: 3048107  reaL: 1m49.050s
>
> FIO with zipf:
> Before: 73557.72 MB/s
> After:  74553.44 MB/s
>
> Also, mechanisms like PSI, smap, readahead, will all have better
> accuracy since this series unified the flag usage between classical
> LRU and MGLRU.
>
> This also reduces MGLRU's max flag usage by one, and hopefully provides
> a generic API for other components like DAMON to contribute to MGLRU's
> hotness tracking.
>
> Other tests like the MySQL are looking fine, no regression. Filesearch
> test in [2] also shows some improvement, not comparable to cache_ext, since
> this still need to rely on things like the refault distance to establish a
> pattern before it takes any effect, but more generic.
>
> 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?

Thanks,
Joanne