Messages in this thread | | | Date | Mon, 2 Mar 2015 14:31:57 -0500 | From | Steven Rostedt <> | Subject | Re: [PATCH v2 00/15] tracing: 'hist' triggers |
| |
On Mon, 2 Mar 2015 11:14:54 -0800 Alexei Starovoitov <ast@plumgrid.com> wrote:
> I think we both want to see in-kernel aggregation. > This 'hist' stuff is trying to do counting and even map sorting > in the kernel, whereas with bpf programs I'm moving > all of these decisions to user space. > I understand your desire to avoid any user level scripts > and do everything via 'cat' and debugfs, but imo that's > very limiting. I think it's better to do slim user space > scripting language that can translate to bpf even in > embedded setups. Then users will be able to aggregate > whatever they like, whereas with 'hist' approach > they're limited to simple counters. > trace_events_trigger.c - 1466 lines - that's quite a bit > of code that will be rarely used. Kinda goes counter > to embedded argument. Why add this to kernel > when bpf programs can do the same on demand?
At Collab, a lot of people came to me telling me they love the debugfs system. Because it's everywhere they go. You remove that, you remove most users (including myself).
> Also the arguments about stable ABI apply as well. > The format of 'hist' file would need to be stable, so will > be hard to extend it. With bpf programs doing aggregation > the kernel ABI exposure is much smaller.
I disagree with this statement.
> So would you consider working together on adding > clean bpf+tracepoints infra and corresponding > user space bits? > We can have small user space parser/compiler for > 'hist:keys=common_pid.execname,id.syscall:vals=hitcount' > strings that will convert it into bpf program and you'll > be able to use it in embedded setups ?
Make sure it also works on android.
-- Steve
| |