Re: [PATCH 1/2] perf cs-etm: Change tuple from traceID-CPU# to traceID-metadata

From: Salvatore Bonaccorso <carnil@debian.org>
To: stable@vger.kernel.org
Cc: Andrey Zhizhikin <andrey.z@gmail.com>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	Suzuki K Poulouse <suzuki.poulose@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	coresight ml <coresight@lists.linaro.org>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	Leo Yan <leo.yan@linaro.org>, Namhyung Kim <namhyung@kernel.org>,
	Robert Walker <robert.walker@arm.com>,
	Jiri Olsa <jolsa@redhat.com>,
	linux-arm-kernel@lists.infradead.org,
	Mike Leach <mike.leach@linaro.org>
Subject: Re: [PATCH 1/2] perf cs-etm: Change tuple from traceID-CPU# to traceID-metadata
Date: Wed, 25 Nov 2020 21:23:23 +0100	[thread overview]
Message-ID: <X769O4RFFPyfQaDT@eldamar.lan> (raw)
In-Reply-To: <20201125201215.26455-1-carnil@debian.org>

On Wed, Nov 25, 2020 at 09:12:14PM +0100, Salvatore Bonaccorso wrote:
> From: Leo Yan <leo.yan@linaro.org>
> 
> commit 95c6fe970a0160cb770c5dce9f80311b42d030c0 upstream.
> 
> If packet processing wants to know the packet is bound with which ETM
> version, it needs to access metadata to decide that based on metadata
> magic number; but we cannot simply to use CPU logic ID number as index
> to access metadata sequential array, especially when system have
> hotplugged off CPUs, the metadata array are only allocated for online
> CPUs but not offline CPUs, so the CPU logic number doesn't match with
> its index in the array.
> 
> This patch is to change tuple from traceID-CPU# to traceID-metadata,
> thus it can use the tuple to retrieve metadata pointer according to
> traceID.
> 
> For safe accessing metadata fields, this patch provides helper function
> cs_etm__get_cpu() which is used to return CPU number according to
> traceID; cs_etm_decoder__buffer_packet() is the first consumer for this
> helper function.
> 
> Signed-off-by: Leo Yan <leo.yan@linaro.org>
> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
> Cc: Jiri Olsa <jolsa@redhat.com>
> Cc: Mike Leach <mike.leach@linaro.org>
> Cc: Namhyung Kim <namhyung@kernel.org>
> Cc: Robert Walker <robert.walker@arm.com>
> Cc: Suzuki K Poulouse <suzuki.poulose@arm.com>
> Cc: coresight ml <coresight@lists.linaro.org>
> Cc: linux-arm-kernel@lists.infradead.org
> Link: http://lkml.kernel.org/r/20190129122842.32041-6-leo.yan@linaro.org
> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> [Salvatore Bonaccorso: Adjust for context changes in
> tools/perf/util/cs-etm-decoder/cs-etm-decoder.c]
> Signed-off-by: Salvatore Bonaccorso <carnil@debian.org>

That's a fallout on my end. Should have said: This is for 4.19
specifically to be queued.

Background: in
https://lore.kernel.org/stable/20201014135627.GA3698844@kroah.com/
168200b6d6ea0cb5765943ec5da5b8149701f36a was queued up for v4.19.y but
the prerequeisite commit was not included and so resulted in build
failures with gcc 8.3.0.

The commit was later on reverted but in this thread it was asked to
actually make it possible to compile the file as well with more recent
gcc versions.

Those two patches to be applied in 4.19.y only pick up a backport of
the rerequisite commit 95c6fe970a0160cb770c5dce9f80311b42d030c0 (PATCH
1) followed up by the cherry-pick of
168200b6d6ea0cb5765943ec5da5b8149701f36a again.

Regards,
Salvatore

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