4 ms·
I 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?
by clktmr 5y ago
I 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?
- drewg123 5y agoIf 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.
- tarasglek 5y agoAuthor 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.
- trasz 5y agoNot Linux, but in FreeBSD page fault tracing is provided by ktrace(8) ('ktrace -t +f').
- markjdb 5y agoI use "ktrace -t f" once in a while for debugging and it's really handy. Output looks like 78436 cat PFLT 0x6c71f99cda8 0x2<VM_PROT_WRITE> 78436 cat PRET KERN_SUCCESS 78436 cat PFLT 0x3c6efd36c280 0x2<VM_PROT_WRITE> 78436 cat PRET KERN_SUCCESS 78436 cat PFLT 0x3c6efd36e158 0x2<VM_PROT_WRITE> 78436 cat PRET KERN_SUCCESS ... Obviously not nearly as flexible as ebpf though. For instance it'll log all page faults happening in the context of the process, and so includes page faults that happen in the kernel due to copyin()/copyout() etc. Sometimes it's helpful and other times confusing.
- deleted 5y ago[deleted]