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

Adrian Hunter
2024-07-18T11:19:14Z

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.

>
>> aux_in_pause_resume to struct perf_buffer to prevent races with the NMI
>> handler. Pause/resume in NMI context will miss out if it coincides with
>> another pause/resume.
>
> I'm struggling here. That variable is only ever used inside that one
> function. So it must be self-recursion. Are you thinking something like:
>
> swevent_overflow()
> ...
> event_aux_pause()
> <NMI>
> event_overflow()
> ...
> event_aux_pause()
>
> ?
>
> Where two events in the group, one software and one hardware, are both
> trying to control the AUX thing?

Exactly that yes.

> Because I don't think the PT-PMI ever
> gets here.

No it doesn't. AUX pause/resume is something a non-AUX event in the
group does to the AUX event which is the group leader.

>
>> To use aux_pause or aux_resume, an event must be in a group with the AUX
>> area event as the group leader.
>
>
>> @@ -402,6 +411,15 @@ struct pmu {
>> *
>> * ->start() with PERF_EF_RELOAD will reprogram the counter
>> * value, must be preceded by a ->stop() with PERF_EF_UPDATE.
>> + *
>> + * ->stop() with PERF_EF_PAUSE will stop as simply as possible. Will not
>> + * overlap another ->stop() with PERF_EF_PAUSE nor ->start() with
>> + * PERF_EF_RESUME.
>> + *
>> + * ->start() with PERF_EF_RESUME will start as simply as possible but
>> + * only if the counter is not otherwise stopped. Will not overlap
>> + * another ->start() with PERF_EF_RESUME nor ->stop() with
>> + * PERF_EF_PAUSE.
>> */
>> void (*start) (struct perf_event *event, int flags);
>> void (*stop) (struct perf_event *event, int flags);
>
> Notably, they *can* race with ->stop/start without EF_PAUSE/RESUME.

Yes that would be worth adding to the comments.