On 2019/4/2 下午3:59, Nikolay Borisov wrote: > > > On 2.04.19 г. 10:41 ч., Qu Wenruo wrote: >> Hi, >> >> I'm recently working on crafting a small bcc based script to show how >> btrfs tree block concurrency. >> >> The prototype is here: >> https://gist.github.com/adam900710/63db6cdc7d26c4744a53dfc7755fafda >> >> However it has some problems, and cannot be used directly on latest kernel. >> >> - No way to pass btrfs headers into eBPF code. >> This is because the declaration of extent_buffer is in >> `fs/btrfs/extent_io.h`. >> No in the common kernel headers search path. >> >> - eBPF program can't access btrfs_header_owner() helper. >> Even we make eBPF code understand the headers, we can't >> access a lot of kernel functions, like btrfs_header_owner(). >> >> So I'm wondering is it possible for us to export extent_buffer >> declaration just for possible eBPF usage. > > >> Or is bcc suit strong enough to handle such case? >> >> The diff would be something like this to make above bcc script work: >> > > > Hell no, that is _very_ ugly as hell. If you want to access such > information why not introduce tracepoints which have enough context so > that when they are used with ebpf you can query the data from the > tracepoint? I *think* this ought to be made to work with ebpf? The problem is, for kprobe/kretprobe, the only thing they can access is limited C language. I'm not sure if external function call is possible. Another problem is, if using kprobe/kretprobe, entry and return point are 2 separate functions, which means they are independent. Normally we use a hash table and use pid+tgid as index to match return with entry and get the execution time. If using tracepoint, it's pretty static and either we record execution time inside btrfs and export it using regular ftrace events, then the start/end time overhead can't be skipped, it will always be there. Any good idea on that? Or bcc guys have better ideas on this? Thanks, Qu
