On Mon, Mar 2, 2015 at 8:00 AM, Tom Zanussi <tom.zanu...@linux.intel.com> wrote: > > # echo 'hist:keys=common_pid.execname,id.syscall:vals=hitcount' > \ > /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger > > # cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist > > key: common_pid:bash[3112], id:sys_write vals: count:69 > key: common_pid:bash[3112], id:sys_rt_sigprocmask vals: count:218
Hi Tom, 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? 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. 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 ? Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
