On Tue, Nov 3, 2026 at 8:23 PM Ridong Chen <[email protected]> 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. Best, Barry
