Conversation

Jarkko Sakkinen

I think that I do as a next #BPF exercise a "poor man's" flame graph generator for #TPM driver, meaning no interaction and make most of VT output ;-)

I could also consider to do it for #kernel #keyring later on but TPM driver is easier to scope: only look at events that end up to tpm_transmit().

Instead of "perf sampling approach" I'm planning to use BPF ring buffer and use that to all backtraces to tpm_transmit() to the user space host program. Then the host program implemented with C will post-process that queue in parallel.

Frequency of TPM commands is low enough so that 1:1 granularity should be possible.

Can't wait to get this done, will be a fun tool for future patch reviews I make ;-)

#eBPF
1
0
1
I.e. BPF program only passes the backtraces to the ring buffer and no intelligence on that side. All heavy-lifting will be done by the host program. The only shared data structure is a single BPF ring buffer.
1
1
1
I know this looks like crap but it was "enough implementation" for me to be sure that this kind of program is actually doable ;-) Sometimes it is good to optimize for the worst... https://codeberg.org/jarkko/hello-ebpf
1
0
1

Jarkko Sakkinen

Edited 1 month ago
I like bpftool/libbpf approach definitely over bpftrace and Aya.rs. Both add a shimmering layer that masks the view for me too much. Also, bpftrace does not allow to *tailor* the tracing process because it defines one ;-) [and is great for what it is, love it]

I could imagine Aya.rs hit me if I was doing user space profiling. I think it is great too but sub-optimally heavy for my needs...
0
0
1