[PATCH V9 02/13] perf/core: Add aux_pause, aux_resume, aux_start_paused

[Peter Zijlstra]

On Thu, Jul 18, 2024 at 02:19:03PM +0300, Adrian Hunter wrote:
> On 18/07/24 12:38, Peter Zijlstra wrote:
> > On Mon, Jul 15, 2024 at 07:07:01PM +0300, Adrian Hunter wrote:
> >> Hardware traces, such as instruction traces, can produce a vast amount of
> >> trace data, so being able to reduce tracing to more specific circumstances
> >> can be useful.
> >>
> >> The ability to pause or resume tracing when another event happens, can do
> >> that.
> >>
> >> Add ability for an event to "pause" or "resume" AUX area tracing.
> >>
> >> Add aux_pause bit to perf_event_attr to indicate that, if the event
> >> happens, the associated AUX area tracing should be paused. Ditto
> >> aux_resume. Do not allow aux_pause and aux_resume to be set together.
> >>
> >> Add aux_start_paused bit to perf_event_attr to indicate to an AUX area
> >> event that it should start in a "paused" state.
> >>
> >> Add aux_paused to struct hw_perf_event for AUX area events to keep track of
> >> the "paused" state. aux_paused is initialized to aux_start_paused.
> >>
> >> Add PERF_EF_PAUSE and PERF_EF_RESUME modes for ->stop() and ->start()
> >> callbacks. Call as needed, during __perf_event_output(). Add
> > 
> > Why in __perf_event_output() rather than in __perf_event_overflow().
> > Specifically, before bpf_overflow_handler().
> > 
> > That is, what do we want BPF to be able to do here? To me it seems
> > strange that BPF would be able to affect this functionality. You want
> > this pause/resume to happen irrespective of how the rest of the event is
> > processed, no?
> 
> The thought was to have the output match up with pause/resume, but it
> doesn't really make much difference.
> 
> Putting it before the BPF handler is reasonable.

OK, let me do that and make a few more edits and see if I can stare at
that next patch some.