|
|
|
|
|
|
by lathiat
953 days ago
|
|
|
I have been talking about someone needing to do this recently, uprobes are largely quite slow for tracing (e.g. with bpftrace) because it has to trap into the kernel every single time, unlike tracing anything in the kernel because you're already in the kernel - so no context switch is needed. It was always possible to do something like this, to inject the bpf code to run in-process and only export data occasionally just like the kernel side version - and the pieces already existed but no one had put all the pieces together, now someone has. Awesome! Just need someone to implement this seamlessly into bpftrace :) That would be amazing! If you want to understand why it's slow without this, I recently did a talk explaining the difference in tracing speed between strace and bpftrace (when tracing things in the kernel) that may help! In this case (which I didn't really cover), most function uprobes have to trap into the kernel and back twice (once on function entry and once on return, I explain why) - not as bad as the full strace example I explain in detail in the video - but still comparatively expensive. https://www.youtube.com/watch?v=ZDTfcrp9pJI "bpftrace recipes: 5 real problems solved" I re-ran this talk (mostly the same, a few minor updates) at the Riga Ubuntu Summit a couple of weeks ago but the videos aren't up yet. But the version above is mostly the same and was a pretty good recording :) |
|
|
In fact, bpftime can already run bpftrace in userspace for uprobes, without any modification: https://github.com/eunomia-bpf/bpftime/tree/master/example/b...
(There might still need some bug fixes in some cases, e.g. the signal handler to stop the bpf program…
Maybe we can integrate the bpftime agent and attach mechanism in bpftrace, so it can be released together?