On Wed, Aug 3, 2016 at 2:48 AM, Peter Zijlstra <pet...@infradead.org> wrote: > > On Wed, Aug 03, 2016 at 02:47:47AM +0000, Brendan Gregg wrote: > > When perf is performing hrtimer-based sampling, this tracepoint can be used > > by BPF to run additional logic on each sample. For example, BPF can fetch > > stack traces and frequency count them in kernel context, for an efficient > > profiler. > > Urgh, no like. > > And then next week we'll add a tracepoint to some other random pmu or > whatnot.
I wouldn't want random pmu tracepoints either, but I can see how it looks with a new tracepoint category of "perf:", and maybe I shouldn't have called it that. Would it be better if the tracepoint was called "timer:perf_hrtimer"? As for pmu tracepoints: if I were to instrument it (although I wasn't planning to), I'd put a tracepoint in perf_event_overflow() called "perf:perf_overflow", with the same arguments. That could then be used for all PMU overflow events, without needing to add specific tracepoints. The "perf:" category would then have two tracepoints, and would not need to grow. Does that option sound better than "timer:perf_hrtimer"? (As in, keeping the category "perf" so that we have a later option of adding a perf:perf_overflow tracepoint if need be?) It's really perf_hrtimer that we'll use daily, for CPU profiling with in-kernel aggregations of instruction pointers and stack traces, and other sampling needs. It's one tracepoint that will add much value, and will mean that BPF programs can then be attached to kprobes, uprobes, tracepoints, and timed samples. Thanks for your consideration, Brendan
