[DTrace-devel] [PATCH 1/3] Cache per-CPU agg map IDs
Nick Alcock
nick.alcock at oracle.com
Wed Jul 16 13:20:40 UTC 2025
On 1 May 2025, eugene loh outgrape:
> From: Eugene Loh <eugene.loh at 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 at oracle.com>
Reviewed-by: Nick Alcock <nick.alcock at oracle.com>
(as long as Kris is happy with this probably-theoretical slowdown.)
--
NULL && (void)
More information about the DTrace-devel
mailing list