eBPF for tracing how Firefox uses page faults to load libraries
1–10 of 21 posts
Re: eBPF for tracing how Firefox uses page faults to load libraries
#2I haven't tried my hands at eBPF yet. But wouldn't it be easier to just use strace() as long as you are only interested in syscalls?
Re: eBPF for tracing how Firefox uses page faults to load libraries
#3I went to go learn more about eBPF, but the ebpf.io site reads like a sales pitch. "Revolutionary technology", "The possibilities are endless, and the innovation that eBPF is unlocked has only just begun", "revolutionary new approaches", "unprecedented visibility".
I know I may be a curmudgeonly old fart, but to echo clktmr's comment, in this case, it seems like a glorified strace(). It also seems like a lot of hype for something that seems to have potential to have lots of unintended consequences.
Re: eBPF for tracing how Firefox uses page faults to load libraries
#4I haven't tried my hands at eBPF yet. But wouldn't it be easier to just use strace() as long as you are only interested in syscalls?
If you're only interested in syscalls, then yes. But a library's memory is mmaped (syscall), which just establishes a virtual address mapping for the library file. When the library is accessed, that mmap'ed region is faulted in (not a syscall). This is something where you need eBFP (or dtrace, etc) to see what's happening.
Re: eBPF for tracing how Firefox uses page faults to load libraries
#5I haven't tried my hands at eBPF yet. But wouldn't it be easier to just use strace() as long as you are only interested in syscalls?
Author here.
strace wouldn't work for this. Need to track individual page faults + their addresses. Problem with memory-mapped IO is that it's all done by memory-access "side-effects".
The strace-like functionality is supposedly more efficient and is more convenient.
Re: eBPF for tracing how Firefox uses page faults to load libraries
#6I went to go learn more about eBPF, but the ebpf.io site reads like a sales pitch. "Revolutionary technology", "The possibilities are endless, and the innovation that eBPF is unlocked has only just begun", "revolutionary new approaches", "unprecedented visibility". I know I may be a curmudgeonly old fart, but to echo clktmr's comment, in this case, it seems like a glorified strace(). It also seems like a lot of hype…
eBPF is much more than a glorified strace(): with eBPF you can basically inserts your own code in a lot of places in the kernel.
This can be packet-processing code to modify the way packets are routed, filtered, altered, or it can be used to instrument kernel codepath to monitor or debug issues.
The latter is what can be compared to strace(), but with strace() you only see what is happening at the userspace/kernel boundary. With eBPF you can actually look at what is going on in the kernel itself, which is really powerful.
The downside is that eBPF can be a pain to use with all those obscure tools tightly dependents upon your kernel release and options... But things are improving quickly and if you want to give it a try, I would recommend starting with bpftrace: https://bpftrace.org/
Re: eBPF for tracing how Firefox uses page faults to load libraries
#7I went to go learn more about eBPF, but the ebpf.io site reads like a sales pitch. "Revolutionary technology", "The possibilities are endless, and the innovation that eBPF is unlocked has only just begun", "revolutionary new approaches", "unprecedented visibility". I know I may be a curmudgeonly old fart, but to echo clktmr's comment, in this case, it seems like a glorified strace(). It also seems like a lot of hype…
It's a glorified strace in the same way that gcc is a glorified hello world
Re: eBPF for tracing how Firefox uses page faults to load libraries
#8I went to go learn more about eBPF, but the ebpf.io site reads like a sales pitch. "Revolutionary technology", "The possibilities are endless, and the innovation that eBPF is unlocked has only just begun", "revolutionary new approaches", "unprecedented visibility". I know I may be a curmudgeonly old fart, but to echo clktmr's comment, in this case, it seems like a glorified strace(). It also seems like a lot of hype…
I've written my BSc thesis on Kubernetes bandwidth management with eBPF a year ago. This is exactly what I felt trying to research this technology. Countless blog posts about how great eBPF is, close to none useful resources... And from what I've seen since, it's only gotten marginally better.
Re: eBPF for tracing how Firefox uses page faults to load libraries
#9I went to go learn more about eBPF, but the ebpf.io site reads like a sales pitch. "Revolutionary technology", "The possibilities are endless, and the innovation that eBPF is unlocked has only just begun", "revolutionary new approaches", "unprecedented visibility". I know I may be a curmudgeonly old fart, but to echo clktmr's comment, in this case, it seems like a glorified strace(). It also seems like a lot of hype…
I've written my BSc thesis on Kubernetes bandwidth management with eBPF a year ago. This is exactly what I felt trying to research this technology. Countless blog posts about how great eBPF is, close to none useful resources... And from what I've seen since, it's only gotten marginally better.
Brendan Gregg's writings are pretty good.
https://www.brendangregg.com/blog/2019-01-01/learn-ebpf-trac...
Re: eBPF for tracing how Firefox uses page faults to load libraries
#10I haven't tried my hands at eBPF yet. But wouldn't it be easier to just use strace() as long as you are only interested in syscalls?
Not Linux, but in FreeBSD page fault tracing is provided by ktrace(8) ('ktrace -t +f').