[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0d433917-f638-4ca6-ba6a-1d5e85895024@arm.com>
Date: Tue, 7 May 2024 12:05:44 +0100
From: Suzuki K Poulose <suzuki.poulose@....com>
To: James Clark <james.clark@....com>, linux-perf-users@...r.kernel.org,
gankulkarni@...amperecomputing.com, scclevenger@...amperecomputing.com,
coresight@...ts.linaro.org, mike.leach@...aro.org
Cc: Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Namhyung Kim <namhyung@...nel.org>, Mark Rutland <mark.rutland@....com>,
Jiri Olsa <jolsa@...nel.org>, Ian Rogers <irogers@...gle.com>,
Adrian Hunter <adrian.hunter@...el.com>, John Garry
<john.g.garry@...cle.com>, Will Deacon <will@...nel.org>,
Leo Yan <leo.yan@...ux.dev>, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, linux-stm32@...md-mailman.stormreply.com
Subject: Re: [PATCH 16/17] coresight: Re-emit trace IDs when the sink changes
in per-thread mode
On 29/04/2024 16:22, James Clark wrote:
> In per-cpu mode there are multiple aux buffers and each one has a
> fixed sink, so the hw ID mappings which only need to be emitted once
> for each buffer, even with the new per-sink trace ID pools.
>
> But in per-thread mode there is only a single buffer which can be
> written to from any sink with now potentially overlapping trace IDs, so
> hw ID mappings need to be re-emitted every time the sink changes.
>
> This will require a change in Perf to track this so it knows which
> decode tree to use for each segment of the buffer. In theory it's also
> possible to look at the CPU ID on the AUX records, but this is more
> consistent with the existing system, and allows for correct decode using
> either mechanism.
>
> Signed-off-by: James Clark <james.clark@....com>
> ---
> drivers/hwtracing/coresight/coresight-etm-perf.c | 14 ++++++++++++++
> drivers/hwtracing/coresight/coresight-etm-perf.h | 2 ++
> 2 files changed, 16 insertions(+)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
> index f07173aa4d66..08f3958f9367 100644
> --- a/drivers/hwtracing/coresight/coresight-etm-perf.c
> +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
> @@ -499,6 +499,20 @@ static void etm_event_start(struct perf_event *event, int flags)
> &sink->perf_id_map))
> goto fail_disable_path;
>
> + /*
> + * In per-cpu mode there are multiple aux buffers and each one has a
> + * fixed sink, so the hw ID mappings which only need to be emitted once
> + * for each buffer.
> + *
> + * But in per-thread mode there is only a single buffer which can be
> + * written to from any sink with potentially overlapping trace IDs, so
> + * hw ID mappings need to be re-emitted every time the sink changes.
> + */
> + if (event->cpu == -1 && event_data->last_sink_hwid != sink) {
> + cpumask_clear(&event_data->aux_hwid_done);
> + event_data->last_sink_hwid = sink;
> + }
> +
With the traceid caching in the event_data per-cpu , we could avoid this
step ?
Suzuki
Powered by blists - more mailing lists