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? OK, after some though, the overhead for a new tracepoint is pretty small. The only overhead when the tracepoint is disabled is, a ktimer_get_ns() call at the beginning of btrfs_tree_lock() and btrfs_tree_read_lock(). The pairing ktimer_get_ns() call can be embedded into the trace events, so it won't get triggered until that event is enabled. In that case, I think the ebpf can handle it pretty well. Any comment on this new idea? Thanks, Qu
