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

[Baolin Wang <baolin.wang@linux.alibaba.com>]

On 9/7/26 12:57 PM, Kairui Song wrote:
> On Mon, Sep 7, 2026 at 11:29 AM Baolin Wang
> <baolin.wang@linux.alibaba.com> 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!

Thanks for taking a look.

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

Probably.

> 
> 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'm not sure if there are other hardware environment differences. I 
agree that for complex changes or optimizations, we need to cover more 
test cases than just the kernel build workload, such as the test 
coverage in your MGLRU-FG work.

However, for the current patch, I think it's more about correcting the 
correctness of the promotion mechanism, and the goal is not merely 
performance optimization. If we stack more changes on top of the current 
broken mechanism, I'm afraid future optimizations will become more 
fragile. So let's first reach agreement on the underlying promotion 
mechanism.

Also, as I replied to Barry, the promotion in lru_gen_set_refs() needs 
to be reconsidered as well. It similarly requires clearing reference 
counters before promotion.

So for this simple mechanism correction, I only evaluated the kernel 
build (which is still somewhat representative as a comprehensive 
workload) and it did not introduce a regression (which is fortunate). I 
wouldn't want any workload to rely on this incorrect logic for 
performance gains.

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

The LRU_REFS_WIDTH is always 2 on my setup.