Re: [PATCH] mm: mglru: clear the reference counter for rejected folios

[Kairui Song]

On Mon, Sep 7, 2026 at 11:29 AM Baolin Wang
<baolin.wang@xxxxxxxxxxxxxxxxx> wrote:
>
> As per the comment on LRU_REFS_FLAGS, when accessed folios are promoted to
> a new generation, LRU_REFS_FLAGS should be cleared so that the reference
> counter can start over.
>
> For folios rejected by shrink_folio_list(), we clear LRU_REFS_FLAGS and
> set the PG_active flag if the rejected folio is planned to be put back to
> the oldest generation. That's fine.
>
> But for those that are not put back to the oldest generation (which can
> be treated as a promotion), we do not clear LRU_REFS_FLAGS, which can
> violate the promotion mechanism. This means the rejected folio enters the
> new generation with stale, inflated tier bits, which can inflate reference
> counts and distort eviction statistics for these rejected folios.
>
> Fix this by clearing LRU_REFS_FLAGS for rejected folios, and also do some
> measurement. On my 32-core Arm machine, with the memcg limit set to 3G,
> running 'make -j32' to build the kernel showed a small improvement in sys
> time when using either a zram or NVMe swap device (averaged over 2 runs with
> no significant variance).
>
> zram swap:
>                 w/o patch       w/ patch
> sys time:       1666.5s         1589.5s
>
> NVMe swap:
>                 w/o patch       w/patch
> sys time:       760s            741.5s

Hi Baolin,

Thanks for the patch, it makes sense and I like the idea!

However, I find it interesting that your test setup shows such a
significant benefit with several recent changes when I can't observe a
performance gain on any of my setups. I'm a bit worried this (not only
this patch) might be overfitting into to the kernel build test on
specific setups.

I did try this optimization before and found no gain, maybe it is
somehow tangled with some other recent upstream changes?

For example a few recently landed MGLRU optimizations sped up the ZRAM
kernel build test on your setup, but slowed down many other cases.

I still think this is mergable, but before that, do you have the
LRU_REFS_WIDTH data from your kernel build? Or lru_gen_full output? In
some cases it shrinks to only 1 or 0 bits, leading to very different
performance readings.