Re: [DTrace-devel] [PATCH 1/3] Cache per-CPU agg map IDs

[Nick Alcock <nick.alcock@oracle.com>]

On 1 May 2025, eugene loh outgrape:

> From: Eugene Loh <eugene.loh@oracle.com>
>
> The dt_bpf_map_lookup_fd(dtp->dt_aggmap_fd, &cpu) call that is used to
> snap or truncate aggregations takes a few milliseconds, which seems all
> right.  For large systems (e.g., 100 CPUs) and many truncations (e.g.,
> tst.trunc.d, etc.), however, a trunc() might end up costing a minute on
> the consumer side, which is unreasonable and causes such tests to time
> out.  The run time is due almost exclusively to looking up the per-CPU
> agg map ID.

... how on earth did you figure this out? Some sort of profiler,
presumably...

> Cache the per-CPU agg map IDs.

LGTM, doing the slow operation only once rather than once per snap seems
sensible. (If this turns out to slow down the no-aggs case too much,
we could always populate the map just once on the first call to
dtrace_aggregate_snap() and dt_aggwalk_remove(). But presumably just one
operation is fast enough.)

> Signed-off-by: Eugene Loh <eugene.loh@oracle.com>

Reviewed-by: Nick Alcock <nick.alcock@oracle.com>

(as long as Kris is happy with this probably-theoretical slowdown.)

-- 
NULL && (void)