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

[Eugene Loh]

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.