[DTrace-devel] [PATCH 1/2] Add a cpuinfos BPF map

[Eugene Loh]

On 4/1/25 19:03, Kris Van Hees wrote:

> On Tue, Apr 01, 2025 at 06:54:29PM -0400, Eugene Loh wrote:
>> Here is a proposal.  First, two observations:
>>
>> 1.  (As Alan pointed out to me in a facepalm moment), one can write a simple
>> D script to check enqueue_task_*()'s rq->cpu against the current CPU.  He
>> and I both find that the two CPUs are generally -- but not always -- the
>> same.  So, the strictly correct thing to do is use the rq->cpu value, even
>> though you can just use the current CPU and be correct "99%" of the time.
> Sort of what I expected.  But nice to see it confirmed.
>
>> 2.  A BPF program can access per-cpu-array values on other CPUs. Well, I
>> guess you need commit 0734311 ("bpf: add bpf_map_lookup_percpu_elem for
>> percpu map").  That's in 5.18. That is, UEK9.
> We oculd get that backported I bet but that doesn't help upstream.  So, not
> really worth asking for a backport I think.
>
>> So my proposal is to leave the per-cpu cpuinfo BPF map alone. Perform a
>> runtime test whether bpf_map_lookup_percpu_elem() is available.  If so, do
>> that cross-CPU lookup -- the 2/2 patch I posted -- but using the new helper
>> function.  If not, use a simpler on-CPU lookup, which should be right "99%"
>> of the time. (I have a simple patch that uses the current CPU.  Pretty
>> simple.)
> But...  95% correct of the time doesn't quite cut it.  I could see some quite
> useful case for using these probes to specifically capture the times when it
> does *not* originate from the same CPU.  Settling for 95% correctness seems
> like an odd tradeoff to me.  Especally since we can get it right 100% of the
> time without too much trouble.  Just convert the cpuinfo map to a regular
> array map, and instead of indexing it with a 0 key all the time, index it with
> the value returned by bpf_get_smp_processor_id(().  Then we have code that will
> work on all kernels - no special casing.  And I do not see there being much
> performance difference by going this route.

This patch is withdrawn.