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 14:36:58 -0800
Alexei Starovoitov <ast@plumgrid.com> wrote:

> On Thu, Dec 5, 2013 at 5:46 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > 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.
>
> I don't understand that 'awkward' part yet. What do you mean by 'knowledge of
> the kernel'? By accessing pt_regs structure? Something else ?
> Can we try fixing the interface first before compromising on performance?

Let me ask you this. If you do not have the source of the kernel on
hand, can you use BPF to filter the sched_switch tracepoint on prev pid?

The current filter interface allows you to filter with just what the
running kernel provides. No need for debug info from the vmlinux or
anything else.

pt_regs is not that useful without having something to translate what
that means.

I'm fine if it becomes a requirement to have a vmlinux built with
DEBUG_INFO to use BPF and have a tool like perf to translate the
filters. But it that must not replace what the current filters do now.
That is, it can be an add on, but not a replacement.

-- Steve


\
 
 \ /
  Last update: 2013-12-06 01:41    [W:0.088 / U:0.880 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site