Messages in this thread | | | Date | Tue, 3 Dec 2013 10:33:46 -0500 | From | Steven Rostedt <> | Subject | Re: [RFC PATCH tip 0/5] tracing filters with BPF |
| |
On Tue, 3 Dec 2013 10:16:55 +0100 Ingo Molnar <mingo@kernel.org> wrote:
> So, to do the math: > > tracing 'all' overhead: 95 nsecs per event > tracing 'eth5 + old filter' overhead: 157 nsecs per event > tracing 'eth5 + BPF filter' overhead: 54 nsecs per event > > So via BPF and a fairly trivial filter, we are able to reduce tracing > overhead for real - while old-style filters.
Yep, seems that BPF can do what I wasn't able to do with the normal filters. Although, I haven't looked at the code yet, I'm assuming that the BPF works on the parameters passed into the trace event. The normal filters can only process the results of the trace (what's being recorded) not the parameters of the trace event itself. To get what's recorded, we need to write to the buffer first, and then we decided if we want to keep the event or not and discard the event from the buffer if we do not.
That method does not reduce overhead at all, and only adds to it, as Alexei's tests have shown. The purpose of the filter was not to reduce overhead, but to reduce filling the buffer with needless data.
It looks as if the BPF filter works on the parameters of the trace event and not what is written to the buffers (as they can be different). I've been looking for a way to do just that, and if this does accomplish it, I'll be very happy :-)
-- Steve
| |