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

[Steven Rostedt]

On Thu, 5 Dec 2013 11:41:13 +0100
Ingo Molnar <mingo@xxxxxxxxxx> wrote:

 
> > so with one 'if' condition the difference ktap vs bpf is 350-145 vs 183-145
> > 
> > obviously ktap is an interpreter, so it's not really fair.
> > 
> > To make it really unfair I did:
> > trace skb:kfree_skb {
> >         if (arg2 == 0x100 || arg2 == 0x200 || arg2 == 0x300 || arg2 == 0x400 ||
> >             arg2 == 0x500 || arg2 == 0x600 || arg2 == 0x700 || arg2 == 0x800 ||
> >             arg2 == 0x900 || arg2 == 0x1000) {
> >                 printf("%x %x\n", arg1, arg2)
> >         }
> > }
> > 1M skb alloc/free 484280 (usecs)
> 
> Real life scripts, for examples the ones related to network protocol 
> analysis will often have such patterns in them, so I don't think this 
> measurement is particularly unfair.

I agree. As the size of the if statement grows, the filter logic gets
lineally expensive, but the bpf filter does not.

I know that it would be great to have the bpf filter run before
recording of the tracepoint, but as that becomes quite awkward for a
user interface, because it requires intimate knowledge of the kernel
source, this speed up on the filter itself may be worth while to have
it happen after the recording of the buffer. When it happens after the
record, then the bpf has direct access to the event entry and its
fields as described by the trace event format files.

-- 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/