All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: James Clark <james.clark@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>, Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	John Garry <john.g.garry@oracle.com>,
	Will Deacon <will@kernel.org>, Leo Yan <leo.yan@linux.dev>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-perf-users@vger.kernel.org,
	gankulkarni@os.amperecomputing.com,
	scclevenger@os.amperecomputing.com, coresight@lists.linaro.org,
	mike.leach@linaro.org
Subject: Re: [PATCH 01/17] perf cs-etm: Print error for new PERF_RECORD_AUX_OUTPUT_HW_ID versions
Date: Tue, 7 May 2024 11:54:25 -0300	[thread overview]
Message-ID: <ZjpAoVEam4CQ96zC@x1> (raw)
In-Reply-To: <ecb16ad9-7c91-4cf6-ab7e-4b4b5be7165c@arm.com>

On Tue, May 07, 2024 at 04:27:25PM +0530, Anshuman Khandual wrote:
> On 5/7/24 15:36, James Clark wrote:
> > On 07/05/2024 04:47, Anshuman Khandual wrote:
> >> On 4/29/24 20:51, James Clark wrote:
> >>> The likely fix for this is to update Perf so print a helpful message.
> >>>
> >>> Signed-off-by: James Clark <james.clark@arm.com>
> >>> ---
> >>>  tools/perf/util/cs-etm.c | 5 ++++-
> >>>  1 file changed, 4 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> >>> index d65d7485886c..32818bd7cd17 100644
> >>> --- a/tools/perf/util/cs-etm.c
> >>> +++ b/tools/perf/util/cs-etm.c
> >>> @@ -335,8 +335,11 @@ static int cs_etm__process_aux_output_hw_id(struct perf_session *session,
> >>>  	trace_chan_id = FIELD_GET(CS_AUX_HW_ID_TRACE_ID_MASK, hw_id);
> >>>  
> >>>  	/* check that we can handle this version */
> >>> -	if (version > CS_AUX_HW_ID_CURR_VERSION)
> >>> +	if (version > CS_AUX_HW_ID_CURR_VERSION) {
> >>> +		pr_err("CS ETM Trace: PERF_RECORD_AUX_OUTPUT_HW_ID version %d not supported. Please update Perf.\n",
> >>
> >> Is not this bit misleading ? PERF_RECORD_AUX_OUTPUT_HW_ID is just the perf record
> >> format identifier. The record version here, is derived from the platform specific
> >> hardware ID information embedded in this perf record.
> > 
> > Not sure I follow what you mean here. 'version' is something that's
> > output by the kernel. It's saved into a perf.data file, and if Perf
> > can't handle version 2 for example, you need to update Perf.
 
> Got it.
 
> >> Should not this be just s/PERF_RECORD_AUX_OUTPUT_HW_ID/hardware ID/ instead ?
> >>
> > 
> > It's just a way to go from the error message to the part of the code or
> > docs that you need to look at. "hardware ID" wouldn't lead you anywhere
> > so I don't think it would be useful.
> 
> Sure, fair enough.

I'm taking this as an Acked-by, ok?

- Arnaldo

WARNING: multiple messages have this Message-ID (diff)
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: James Clark <james.clark@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>, Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	John Garry <john.g.garry@oracle.com>,
	Will Deacon <will@kernel.org>, Leo Yan <leo.yan@linux.dev>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-perf-users@vger.kernel.org,
	gankulkarni@os.amperecomputing.com,
	scclevenger@os.amperecomputing.com, coresight@lists.linaro.org,
	mike.leach@linaro.org
Subject: Re: [PATCH 01/17] perf cs-etm: Print error for new PERF_RECORD_AUX_OUTPUT_HW_ID versions
Date: Tue, 7 May 2024 11:54:25 -0300	[thread overview]
Message-ID: <ZjpAoVEam4CQ96zC@x1> (raw)
In-Reply-To: <ecb16ad9-7c91-4cf6-ab7e-4b4b5be7165c@arm.com>

On Tue, May 07, 2024 at 04:27:25PM +0530, Anshuman Khandual wrote:
> On 5/7/24 15:36, James Clark wrote:
> > On 07/05/2024 04:47, Anshuman Khandual wrote:
> >> On 4/29/24 20:51, James Clark wrote:
> >>> The likely fix for this is to update Perf so print a helpful message.
> >>>
> >>> Signed-off-by: James Clark <james.clark@arm.com>
> >>> ---
> >>>  tools/perf/util/cs-etm.c | 5 ++++-
> >>>  1 file changed, 4 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> >>> index d65d7485886c..32818bd7cd17 100644
> >>> --- a/tools/perf/util/cs-etm.c
> >>> +++ b/tools/perf/util/cs-etm.c
> >>> @@ -335,8 +335,11 @@ static int cs_etm__process_aux_output_hw_id(struct perf_session *session,
> >>>  	trace_chan_id = FIELD_GET(CS_AUX_HW_ID_TRACE_ID_MASK, hw_id);
> >>>  
> >>>  	/* check that we can handle this version */
> >>> -	if (version > CS_AUX_HW_ID_CURR_VERSION)
> >>> +	if (version > CS_AUX_HW_ID_CURR_VERSION) {
> >>> +		pr_err("CS ETM Trace: PERF_RECORD_AUX_OUTPUT_HW_ID version %d not supported. Please update Perf.\n",
> >>
> >> Is not this bit misleading ? PERF_RECORD_AUX_OUTPUT_HW_ID is just the perf record
> >> format identifier. The record version here, is derived from the platform specific
> >> hardware ID information embedded in this perf record.
> > 
> > Not sure I follow what you mean here. 'version' is something that's
> > output by the kernel. It's saved into a perf.data file, and if Perf
> > can't handle version 2 for example, you need to update Perf.
 
> Got it.
 
> >> Should not this be just s/PERF_RECORD_AUX_OUTPUT_HW_ID/hardware ID/ instead ?
> >>
> > 
> > It's just a way to go from the error message to the part of the code or
> > docs that you need to look at. "hardware ID" wouldn't lead you anywhere
> > so I don't think it would be useful.
> 
> Sure, fair enough.

I'm taking this as an Acked-by, ok?

- Arnaldo

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2024-05-07 14:54 UTC|newest]

Thread overview: 102+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-29 15:21 [PATCH 00/17] coresight: Use per-sink trace ID maps for Perf sessions James Clark
2024-04-29 15:21 ` James Clark
2024-04-29 15:21 ` [PATCH 01/17] perf cs-etm: Print error for new PERF_RECORD_AUX_OUTPUT_HW_ID versions James Clark
2024-04-29 15:21   ` James Clark
2024-05-07  3:47   ` Anshuman Khandual
2024-05-07  3:47     ` Anshuman Khandual
2024-05-07 10:06     ` James Clark
2024-05-07 10:06       ` James Clark
2024-05-07 10:57       ` Anshuman Khandual
2024-05-07 10:57         ` Anshuman Khandual
2024-05-07 14:54         ` Arnaldo Carvalho de Melo [this message]
2024-05-07 14:54           ` Arnaldo Carvalho de Melo
2024-04-29 15:21 ` [PATCH 02/17] perf auxtrace: Allow number of queues to be specified James Clark
2024-04-29 15:21   ` James Clark
2024-04-30  6:36   ` Adrian Hunter
2024-04-30  6:36     ` Adrian Hunter
2024-05-07  4:26   ` Anshuman Khandual
2024-05-07  4:26     ` Anshuman Khandual
2024-04-29 15:21 ` [PATCH 03/17] perf: cs-etm: Create decoders after both AUX and HW_ID search passes James Clark
2024-04-29 15:21   ` James Clark
2024-04-29 15:21 ` [PATCH 04/17] perf: cs-etm: Allocate queues for all CPUs James Clark
2024-04-29 15:21   ` James Clark
2024-04-29 15:21 ` [PATCH 05/17] perf: cs-etm: Move traceid_list to each queue James Clark
2024-04-29 15:21   ` James Clark
2024-04-29 15:21 ` [PATCH 06/17] perf: cs-etm: Create decoders based on the trace ID mappings James Clark
2024-04-29 15:21   ` James Clark
2024-04-29 15:21 ` [PATCH 07/17] perf: cs-etm: Support version 0.1 of HW_ID packets James Clark
2024-04-29 15:21   ` James Clark
2024-04-29 15:21 ` [PATCH 08/17] coresight: Remove unused stubs James Clark
2024-04-29 15:21   ` James Clark
2024-05-01 11:06   ` Mike Leach
2024-05-01 11:06     ` Mike Leach
2024-05-07  4:15   ` Anshuman Khandual
2024-05-07  4:15     ` Anshuman Khandual
2024-04-29 15:21 ` [PATCH 09/17] coresight: Clarify comments around the PID of the sink owner James Clark
2024-04-29 15:21   ` James Clark
2024-05-01 11:07   ` Mike Leach
2024-05-01 11:07     ` Mike Leach
2024-05-07  4:25   ` Anshuman Khandual
2024-05-07  4:25     ` Anshuman Khandual
2024-04-29 15:21 ` [PATCH 10/17] coresight: Move struct coresight_trace_id_map to common header James Clark
2024-04-29 15:21   ` James Clark
2024-05-01 11:11   ` Mike Leach
2024-05-01 11:11     ` Mike Leach
2024-05-07  5:50   ` Anshuman Khandual
2024-05-07  5:50     ` Anshuman Khandual
2024-04-29 15:21 ` [PATCH 11/17] coresight: Expose map argument in trace ID API James Clark
2024-04-29 15:21   ` James Clark
2024-05-01 10:31   ` Mike Leach
2024-05-01 10:31     ` Mike Leach
2024-05-17 10:09     ` James Clark
2024-05-17 10:09       ` James Clark
2024-05-07  6:00   ` Anshuman Khandual
2024-05-07  6:00     ` Anshuman Khandual
2024-04-29 15:21 ` [PATCH 11/17] coresight: Expose map arugment " James Clark
2024-04-29 15:21   ` James Clark
2024-04-29 15:30   ` James Clark
2024-04-29 15:30     ` James Clark
2024-04-29 15:21 ` [PATCH 12/17] coresight: Make CPU id map a property of a trace ID map James Clark
2024-04-29 15:21   ` James Clark
2024-05-07  6:22   ` Anshuman Khandual
2024-05-07  6:22     ` Anshuman Khandual
2024-05-07  9:57     ` James Clark
2024-05-07  9:57       ` James Clark
2024-04-29 15:21 ` [PATCH 13/17] coresight: Pass trace ID map into source enable James Clark
2024-04-29 15:21   ` James Clark
2024-05-07  6:46   ` Anshuman Khandual
2024-05-07  6:46     ` Anshuman Khandual
2024-05-07 10:49   ` Suzuki K Poulose
2024-05-07 10:49     ` Suzuki K Poulose
2024-04-29 15:22 ` [PATCH 14/17] coresight: Use per-sink trace ID maps for Perf sessions James Clark
2024-04-29 15:22   ` James Clark
2024-05-03  9:43   ` Mike Leach
2024-05-03  9:43     ` Mike Leach
2024-05-03 14:31     ` James Clark
2024-05-03 14:31       ` James Clark
2024-05-07 10:52   ` Suzuki K Poulose
2024-05-07 10:52     ` Suzuki K Poulose
2024-05-17 10:07     ` James Clark
2024-05-17 10:07       ` James Clark
2024-04-29 15:22 ` [PATCH 15/17] coresight: Remove pending trace ID release mechanism James Clark
2024-04-29 15:22   ` James Clark
2024-04-29 15:22 ` [PATCH 16/17] coresight: Re-emit trace IDs when the sink changes in per-thread mode James Clark
2024-04-29 15:22   ` James Clark
2024-05-07 11:05   ` Suzuki K Poulose
2024-05-07 11:05     ` Suzuki K Poulose
2024-05-17 10:01     ` James Clark
2024-05-17 10:01       ` James Clark
2024-04-29 15:22 ` [PATCH 17/17] coresight: Emit HW_IDs for all ETMs that are using the sink James Clark
2024-04-29 15:22   ` James Clark
2024-05-03 12:40 ` [PATCH 00/17] coresight: Use per-sink trace ID maps for Perf sessions Mike Leach
2024-05-03 12:40   ` Mike Leach
2024-05-17 10:45   ` James Clark
2024-05-17 10:45     ` James Clark
2024-05-03 20:23 ` Arnaldo Carvalho de Melo
2024-05-03 20:23   ` Arnaldo Carvalho de Melo
2024-05-07 10:01   ` James Clark
2024-05-07 10:01     ` James Clark
2024-05-07 14:59     ` Arnaldo Carvalho de Melo
2024-05-07 14:59       ` Arnaldo Carvalho de Melo
2024-05-07 11:02 ` Ganapatrao Kulkarni
2024-05-07 11:02   ` Ganapatrao Kulkarni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZjpAoVEam4CQ96zC@x1 \
    --to=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=anshuman.khandual@arm.com \
    --cc=coresight@lists.linaro.org \
    --cc=gankulkarni@os.amperecomputing.com \
    --cc=irogers@google.com \
    --cc=james.clark@arm.com \
    --cc=john.g.garry@oracle.com \
    --cc=jolsa@kernel.org \
    --cc=leo.yan@linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=mark.rutland@arm.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=mike.leach@linaro.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=scclevenger@os.amperecomputing.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.