Re: [RFC PATCH tip 0/5] tracing filters with BPF

[Steven Rostedt]

On Tue, 3 Dec 2013 10:16:55 +0100
Ingo Molnar <mingo@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/