Re: [PATCH v5 4/6] mm/vmscan: pass scan_control to the vmscan tracepoints

[Muchun Song]

> On Oct 31, 2026, at 17:00, Ridong Chen <ridong.chen@xxxxxxxxx> wrote:
> 
> From: Ridong Chen <chenridong@xxxxxxxxxx>
> 
> Several vmscan tracepoints spell out reclaim state as individual
> arguments, all of which the caller already holds in struct scan_control.
> Now that the struct is visible from the trace header, pass sc directly
> and pick the fields out in TP_fast_assign instead of spelling them out
> at every callsite:
> 
> - mm_vmscan_direct_reclaim_begin, mm_vmscan_memcg_reclaim_begin and
>  mm_vmscan_node_reclaim_begin: gfp_mask and order.
> 
> - mm_vmscan_lru_isolate, mm_vmscan_lru_shrink_inactive and
>  mm_vmscan_lru_shrink_active: reclaim_idx, order and priority.
> 
> - mm_vmscan_reclaim_pages: nr_scanned. nr_reclaimed stays a separate
>  argument: it is the return value of shrink_folio_list(), which does
>  not update sc->nr_reclaimed.
> 
> - mm_vmscan_balance_pgdat_end: order and nr_reclaimed. highest_zoneidx
>  stays a separate argument: it is a balance_pgdat() parameter, and
>  sc.reclaim_idx may differ from it by the time the end event fires.
> 
> No functional change. The tracefs event format (TP_STRUCT__entry and
> TP_printk) is unchanged, so tracefs-based consumers are unaffected.
> BPF programs attached via raw_tp/tp_btf see the new TP_PROTO and need
> to be adjusted; tracepoints are not a stable ABI (see
> Documentation/bpf/bpf_design_QA.rst).
> 
> Signed-off-by: Ridong Chen <chenridong@xxxxxxxxxx>

Acked-by: Muchun Song <muchun.song@xxxxxxxxx>

Thanks