Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

On Fri, Aug 05, 2016 at 12:45:07PM -0700, Alexei Starovoitov wrote: > Also thinking about concurrency and the need to remember the original > handler somewhere, would it be cleaner api to add a bit to perf_event_attr > and use attr.config1 as bpf_fd ? attr.config[12] are in use already,

Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

On Fri, Aug 05, 2016 at 12:45:07PM -0700, Alexei Starovoitov wrote: > Also thinking about concurrency and the need to remember the original > handler somewhere, would it be cleaner api to add a bit to perf_event_attr > and use attr.config1 as bpf_fd ? attr.config[12] are in use already,

Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

On Fri, Aug 05, 2016 at 10:22:08AM -0700, Brendan Gregg wrote: > (Normally I'd use I$ miss overflow, but none of our Linux systems have > PMCs: cloud.) I think I had better not comment on that ;-) > >> > The perf:perf_hrtimer probe point is also reading state mid-way > >> > through a function,

Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

On Fri, Aug 05, 2016 at 10:22:08AM -0700, Brendan Gregg wrote: > (Normally I'd use I$ miss overflow, but none of our Linux systems have > PMCs: cloud.) I think I had better not comment on that ;-) > >> > The perf:perf_hrtimer probe point is also reading state mid-way > >> > through a function,

Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

On Fri, Aug 05, 2016 at 12:52:09PM +0200, Peter Zijlstra wrote: > > > > Currently overflow_handler is set at event alloc time. If we start > > > > changing it on the fly with atomic xchg(), afaik things shouldn't > > > > break, since each overflow_handler is run to completion and doesn't > > > >

Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

On Fri, Aug 05, 2016 at 12:52:09PM +0200, Peter Zijlstra wrote: > > > > Currently overflow_handler is set at event alloc time. If we start > > > > changing it on the fly with atomic xchg(), afaik things shouldn't > > > > break, since each overflow_handler is run to completion and doesn't > > > >

Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

On Fri, Aug 5, 2016 at 3:52 AM, Peter Zijlstra wrote: > On Thu, Aug 04, 2016 at 10:24:06PM -0700, Alexei Starovoitov wrote: >> tracepoints are actually zero overhead already via static-key mechanism. >> I don't think Peter's objection for the tracepoint was due to overhead.

Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

On Fri, Aug 5, 2016 at 3:52 AM, Peter Zijlstra wrote: > On Thu, Aug 04, 2016 at 10:24:06PM -0700, Alexei Starovoitov wrote: >> tracepoints are actually zero overhead already via static-key mechanism. >> I don't think Peter's objection for the tracepoint was due to overhead. > > Almost 0, they

Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

On Thu, Aug 04, 2016 at 10:24:06PM -0700, Alexei Starovoitov wrote: > tracepoints are actually zero overhead already via static-key mechanism. > I don't think Peter's objection for the tracepoint was due to overhead. Almost 0, they still have some I$ footprint, but yes. My main worry is that we

Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

On Thu, Aug 04, 2016 at 10:24:06PM -0700, Alexei Starovoitov wrote: > tracepoints are actually zero overhead already via static-key mechanism. > I don't think Peter's objection for the tracepoint was due to overhead. Almost 0, they still have some I$ footprint, but yes. My main worry is that we

Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

On Thu, Aug 04, 2016 at 09:13:16PM -0700, Brendan Gregg wrote: > On Thu, Aug 4, 2016 at 6:43 PM, Alexei Starovoitov > wrote: > > On Thu, Aug 04, 2016 at 04:28:53PM +0200, Peter Zijlstra wrote: > >> On Wed, Aug 03, 2016 at 11:57:05AM -0700, Brendan Gregg wrote: > >> >

Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

On Thu, Aug 04, 2016 at 09:13:16PM -0700, Brendan Gregg wrote: > On Thu, Aug 4, 2016 at 6:43 PM, Alexei Starovoitov > wrote: > > On Thu, Aug 04, 2016 at 04:28:53PM +0200, Peter Zijlstra wrote: > >> On Wed, Aug 03, 2016 at 11:57:05AM -0700, Brendan Gregg wrote: > >> > >> > As for pmu tracepoints:

Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

On Thu, Aug 4, 2016 at 6:43 PM, Alexei Starovoitov wrote: > On Thu, Aug 04, 2016 at 04:28:53PM +0200, Peter Zijlstra wrote: >> On Wed, Aug 03, 2016 at 11:57:05AM -0700, Brendan Gregg wrote: >> >> > As for pmu tracepoints: if I were to instrument it (although I wasn't

Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

On Thu, Aug 4, 2016 at 6:43 PM, Alexei Starovoitov wrote: > On Thu, Aug 04, 2016 at 04:28:53PM +0200, Peter Zijlstra wrote: >> On Wed, Aug 03, 2016 at 11:57:05AM -0700, Brendan Gregg wrote: >> >> > As for pmu tracepoints: if I were to instrument it (although I wasn't >> > planning to), I'd put a

Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

On Thu, Aug 04, 2016 at 04:28:53PM +0200, Peter Zijlstra wrote: > On Wed, Aug 03, 2016 at 11:57:05AM -0700, Brendan Gregg wrote: > > > 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 > >

Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

On Thu, Aug 04, 2016 at 04:28:53PM +0200, Peter Zijlstra wrote: > On Wed, Aug 03, 2016 at 11:57:05AM -0700, Brendan Gregg wrote: > > > 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 > >

Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

On Wed, Aug 03, 2016 at 11:57:05AM -0700, Brendan Gregg wrote: > 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

Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

On Wed, Aug 03, 2016 at 11:57:05AM -0700, Brendan Gregg wrote: > 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

Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

On Wed, Aug 3, 2016 at 2:48 AM, Peter Zijlstra wrote: > > On Wed, Aug 03, 2016 at 02:47:47AM +, 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

Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

On Wed, Aug 3, 2016 at 2:48 AM, Peter Zijlstra wrote: > > On Wed, Aug 03, 2016 at 02:47:47AM +, 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

Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

On Wed, Aug 03, 2016 at 02:47:47AM +, 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 >

Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

On Wed, Aug 03, 2016 at 02:47:47AM +, 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 >

[PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

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. Signed-off-by: Brendan Gregg Cc: Alexei

[PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

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. Signed-off-by: Brendan Gregg Cc: Alexei Starovoitov Cc: Wang