Messages in this thread Patch in this message | | | Date | Mon, 25 Jan 2021 11:25:17 +0100 | From | Peter Zijlstra <> | Subject | Re: [RFC PATCH] perf: Handle multiple formatted AUX records |
| |
On Fri, Jan 22, 2021 at 03:18:29PM +0000, Suzuki K Poulose wrote: > CoreSight PMU supports aux-buffer for the ETM tracing. The trace > generated by the ETM (associated with individual CPUs, like Intel PT) > is captured by a separate IP (CoreSight TMC-ETR/ETF until now). > > The TMC-ETR applies formatting of the raw ETM trace data, as it > can collect traces from multiple ETMs, with the TraceID to indicate > the source of a given trace packet. > > Arm Trace Buffer Extension is new "sink" IP, attached to individual > CPUs and thus do not provide additional formatting, like TMC-ETR. > > Additionally, a system could have both TRBE *and* TMC-ETR for > the trace collection. e.g, TMC-ETR could be used as a single > trace buffer to collect data from multiple ETMs to correlate > the traces from different CPUs. It is possible to have a > perf session where some events end up collecting the trace > in TMC-ETR while the others in TRBE. Thus we need a way > to identify the type of the trace for each AUX record. > > This patch adds a new flag to indicate the trace format > for the given record. Also, includes the changes that > demonstrates how this can be used in the CoreSight PMU > to solve the problem. > > Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> > ---
> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h > index b15e3447cd9f..ea7dcc7b30f0 100644 > --- a/include/uapi/linux/perf_event.h > +++ b/include/uapi/linux/perf_event.h > @@ -1109,6 +1109,7 @@ enum perf_callchain_context { > #define PERF_AUX_FLAG_OVERWRITE 0x02 /* snapshot from overwrite mode */ > #define PERF_AUX_FLAG_PARTIAL 0x04 /* record contains gaps */ > #define PERF_AUX_FLAG_COLLISION 0x08 /* sample collided with another */ > +#define PERF_AUX_FLAG_ALT_FMT 0x10 /* this record is in alternate trace format */
Since we have a whole u64, do we want to reserve a whole nibble (or maybe even a byte) for a format type? Because with a single bit like this, we'll kick ourselves when we end up with the need for a 3rd format type.
| |