Re: [PATCH v6 7/7] mm/mglru: add tracepoint for inc_max_seq()

[Ridong Chen]

On 11/4/2026 2:28 AM, Barry Song wrote:
> On Tue, Nov 3, 2026 at 8:23 PM Ridong Chen <ridong.chen@xxxxxxxxx> wrote:
> [...]
> > Hi Barry,
> >
> > Agreed, I'll go with option 2. Two things I'd like to confirm first:
> >
> > 1) To report the reason, should_run_aging() would need to return it
> >    instead of a bool, e.g. an enum like:
> >
> >     enum lru_gen_aging_reason {
> >          AGING_NONE,
> >          AGING_NO_EVICTABLE,     /* eviction is not possible anymore */
> >          AGING_MIN_GENS,         /* better to age, eviction still possible */
> >     };
> >
> > Or just report sc->priority, swappiness, max_seq/min_seq and the
> > per-generation nr_pages, and let users derive the reason from them?
> > The former is more direct, the latter keeps should_run_aging()
> > unchanged.
>
> Right. We can let users infer the reason from max_seq,
> min_seq, and nr_pages in each generation. This shouldn't
> be difficult, especially since should_run_aging() may
> change. We don't need to spell out the exact reason.
> Just present users with the overall state of the lru_gen.
>
> > 2) try_to_shrink_lruvec() has changed quite a lot recently, e.g.
> > Kairui's reclaim loop rework, and your swappiness series also touches it,
> > including the aging part. Is it stable enough now to carry a tracepoint there?
>
> Yes, I think aging will always be needed, regardless of how
> we change the code, so this should remain stable.

Thank you for your patience. That makes sense to me.

Will update.

--
Best regards
Ridong