Messages in this thread | | | Date | Thu, 5 Dec 2013 18:37:35 -0500 | From | Steven Rostedt <> | Subject | Re: [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
| |