[DTrace-devel] [PATCH 1/3] Cache per-CPU agg map IDs
Eugene Loh
eugene.loh at oracle.com
Wed Jul 16 18:42:58 UTC 2025
On 7/16/25 09:20, Nick Alcock wrote:
> 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...
I wish I could say "gprofng" but the first thing is figuring out under
what conditions what was happening. Once I knew where to look for what,
I just happened to stick in some timing calls to nail down the culprit.
Could have been gprofng, I suppose.
More information about the DTrace-devel
mailing list