lkml.org 
[lkml]   [2013]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH tip 0/5] tracing filters with BPF
On Thu, 5 Dec 2013 11:41:13 +0100
Ingo Molnar <mingo@kernel.org> 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


\
 
 \ /
  Last update: 2013-12-05 15:21    [W:0.236 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site