Re: [PATCH v3 2/2] mm/mglru: maintain workingset refault context across state transitions

[Kairui Song]

On Mon, Mar 16, 2026 at 1:56 PM Leno Hou via B4 Relay
<devnull+lenohou.gmail.com@xxxxxxxxxx> wrote:
>
> From: Leno Hou <lenohou@xxxxxxxxx>
>
> When MGLRU state is toggled dynamically, existing shadow entries (eviction
> tokens) lose their context. Traditional LRU and MGLRU handle workingset
> refaults using different logic. Without context, shadow entries
> re-activated by the "wrong" reclaim logic trigger excessive page
> activations (pgactivate) and system thrashing, as the kernel cannot
> correctly distinguish if a refaulted page was originally managed by
> MGLRU or the traditional LRU.
>
> This patch introduces shadow entry context tracking:
>
> - Encode MGLRU origin: Introduce WORKINGSET_MGLRU_SHIFT into the shadow
>   entry (eviction token) encoding. This adds an 'is_mglru' bit to shadow
>   entries, allowing the kernel to correctly identify the originating
>   reclaim logic for a page even after the global MGLRU state has been
>   toggled.

Hi Leno,

I really don't think it's a good idea to waste one bit there just for
the transition state which is rarely used. And if you switched between
MGLRU / non-MGLRU then the refault distance check is already kind of
meaning less unless we unify their logic of reactivation.

BTW I tried that sometime ago: https://lwn.net/Articles/945266/

>
> - Refault logic dispatch: Use this 'is_mglru' bit in workingset_refault()
>   and workingset_test_recent() to dispatch refault events to the correct
>   handler (lru_gen_refault vs. traditional workingset refault).

Hmm, restoring the folio ref count in MGLRU is not the same thing as
reactivation or restoring the workingset flag in non-MGLRU case, and
not really comparable. Not sure this will be helpful.

Maybe for now we just igore this part, shadow is just a hint after
all, switch the LRU at runtime is already a huge performance impact
factor and not recommend, that the shadow part is trivial compared to
that.