Re: [RFC PATCH 1/2] perf: Add the flag sample_disable not to output data on samples

[Alexei Starovoitov]

On 10/12/15 7:30 PM, xiakaixu wrote:
> > The proper perf_event_enable/disable are so heavy that another
> > >mechanism needed? cpu_function_call is probably too much to do
> > >from bpf program, but that can be simplified?
> > >Based on the use case from cover letter, sounds like you want
> > >something like soft_disable?
> > >Then extending event->state would make the most sense.
> > >Also consider the case of re-entrant event enable/disable.
> > >So inc/dec of a flag may be needed?
> Thanks for your comments!
> I've tried perf_event_enable/disable, but there is a warning caused
> by cpu_function_call. The main reason as follows,
>   int smp_call_function_single(...)
>   {
> 	...
> 	WARN_ON_ONCE(cpu_online(this_cpu) && irqs_disabled()
> 		     && !oops_in_progress);

of course, that's what I meant by 'cpu_function_call is too much
to do from bpf program'. In this case it's running out of kprobe
with disabled irq, so you hit the warning, but even if it was regular
tracepoint, doing ipi from bpf is too much. All bpf helpers must be
deterministic without such side effects.

> So I added the extra atomic flag filed in order to avoid this problem.

that's a hammer approach. There are other ways to do it, like:
- extend event->state with this soft_disable-like functionality
 (Also consider the case of re-entrant event enable/disable.
  inc/dec may be needed)
- or tap into event->attr.sample_period
  may be it can be temporarily set to zero to indicate soft_disabled.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/