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

[Ridong Chen <ridong.chen@linux.dev>]

On 11/4/2026 2:28 AM, Barry Song wrote:
> On Tue, Nov 3, 2026 at 8:23 PM Ridong Chen <ridong.chen@linux.dev> 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