On Mon, 9 Feb 2015 19:45:53 -0800 Alexei Starovoitov <ast@xxxxxxxxxxxx> wrote: > So the overhead of realistic bpf program is 5.05963/4.80074 = ~5% > which is faster than perf_event filtering: 5.69732/4.80074 = ~18% > or ftrace filtering: 6.50091/4.80074 = ~35% Come to think of it, this is comparing apples to oranges, as you move the filtering before the recording. It would be interesting to see the ftrace speed up, if it were to use eBPF instead of its own filtering. Maybe that 35% is the filter part, and not the discard part. I just tried the dd test with count==1234 and count!=1234 and the one that drops events is only slightly slower. In this case it does seem that the most overhead is in the filter logic. But by moving it before the recording, we can not use the fields defined in the format files, as the parameters and the fields do not match in most trace points. And to use the parameters, as I have stated, there's no interface to know what those parameters are, then filtering on them is a one shot deal. Might as well write a module and hook directly to the tracepoint and do the filtering natively. That would be faster than BPF too. My point is, what's the use case? If you filter before recording, you can not use the fields of the tracepoint. That limits you to filtering only syscalls, and perhaps kprobes. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
