Re: [PATCH] mm: workingset: judge cross-memcg refaults by generation age

[Barry Song]

On Wed, Aug 26, 2026 at 3:52 PM zhaoyang.huang
<zhaoyang.huang@xxxxxxxxxx> wrote:
>
> From: Zhaoyang Huang <zhaoyang.huang@xxxxxxxxxx>
>
> Unexpected anon folio scan rate is observed in a per-pid topology
> memcgv2's hierarchy even with swappiness=150, which is believed as
> the concequences of belowing rule which discarded all feedback for
> the destination cgroup: no WORKINGSET_REFAULT accounting, no
> activation hint, and no tier or workingset restoration. Shared
> mappings faulted back into another memcg could not signal recent
> usefulness to MGLRU in that cgroup, weakening thrashing detection
> and protection for cross-cgroup file cache and folios that moved
> between memcgs.
>
>         if (lruvec != folio_lruvec(folio))
>                 goto unlock;
>
> The failure mode is structural: min_seq and max_seq are per-lruvec
> generation counters with independent sequences, so their numeric
> gap is meaningless across lruvecs.
>
> Store a truncated eviction timestamp (jiffies) in the shadow token
> next to min_seq, reserving at least 16 bits for min_seq so the
> same-lruvec sequence test does not wrap at the shorter LRU_GEN_WIDTH
> interval. Same-lruvec refaults keep the existing sequence-based
> recency check.
>
> For cross-lruvec refaults, compare elapsed time since eviction with
> the age of the middle generation in the destination lruvec's
> MAX_NR_GENS window. Refaults inside that window are treated as
> recent and workingset feedback is attributed to the destination
> lruvec.
>
> This restores refault-driven reclaim hints for shared cache without
> comparing unrelated generation numbers, while leaving the common
> same-lruvec path unchanged.
>
> With this commit, we can observe the anon scan rate raises under same
> enviroment.

Hi Zhaoyang,

I feel really bad reading these AI-generated changelogs. Could we explain
it in more human terms?

* What is the current problem?
* What is the performance impact?
* What is our approach?
* How does the approach improve performance?

My gut feeling is that you are making workingset refault aware of
cross-lruvec refaults. But I still don't really understand the actual
performance impact or how to reproduce the problem you reported.

What is the user scenario? What kinds of folios can end up on a
different lruvec after being evicted?

Yet you don't provide any performance data, such as anon/file refaults,
sys/user time, or other relevant metrics.

>
> Co-authored-by: Cursor <cursoragent@xxxxxxxxxx>

Do we really allow AI to be listed as a co-author?

Best Regards
Barry