> On Oct 31, 2026, at 17:00, Ridong Chen <[email protected]> wrote:
>
> From: Ridong Chen <[email protected]>
>
> 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 <[email protected]>
Acked-by: Muchun Song <[email protected]>
Thanks