linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Clark <james.clark@arm.com>
To: Leo Yan <leo.yan@linaro.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
	Al Grant <Al.Grant@arm.com>, John Garry <john.garry@huawei.com>,
	Will Deacon <will@kernel.org>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Dave Martin <Dave.Martin@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 1/6] perf arm-spe: Remove unused enum value ARM_SPE_PER_CPU_MMAPS
Date: Thu, 15 Apr 2021 17:49:45 +0300	[thread overview]
Message-ID: <a3a516c5-fc13-50d6-d80f-66f68d1c89c1@arm.com> (raw)
In-Reply-To: <20210415144158.GD1011890@leoy-ThinkPad-X240s>



On 15/04/2021 17:41, Leo Yan wrote:
> Hi James,
> 
> On Thu, Apr 15, 2021 at 05:13:36PM +0300, James Clark wrote:
>> On 12/04/2021 12:10, Leo Yan wrote:
>>> The enum value 'ARM_SPE_PER_CPU_MMAPS' is never used so remove it.
>>
>> Hi Leo,
>>
>> I think this causes an error when attempting to open a newly recorded file
>> with an old version of perf. The value ARM_SPE_AUXTRACE_PRIV_MAX is used here:
>>
>> 	size_t min_sz = sizeof(u64) * ARM_SPE_AUXTRACE_PRIV_MAX;
>> 	struct perf_record_time_conv *tc = &session->time_conv;
>> 	struct arm_spe *spe;
>> 	int err;
>>
>> 	if (auxtrace_info->header.size < sizeof(struct perf_record_auxtrace_info) +
>> 					min_sz)
>> 		return -EINVAL;
>>
>> And removing ARM_SPE_PER_CPU_MMAPS changes the value of ARM_SPE_AUXTRACE_PRIV_MAX.
>>
>> At least I think that's what's causing the problem. I get this error:
>>
>> 	./perf report -i per-thread-spe-time.data
>> 	0x1c0 [0x18]: failed to process type: 70 [Invalid argument]
>> 	Error:
>> 	failed to process sample
>> 	# To display the perf.data header info, please use --header/--header-only options.
>> 	#
> 
> Yes, when working on this patch I had concern as well.
> 
> I carefully thought that the perf tool should be backwards-compatible,
> but there have no requirement for forwards-compatibility.  This is the
> main reason why I kept this patch.
> 
> If you or anyone could confirm the forwards-compatibility is required,
> it's quite fine for me to drop this patch.
> 

Personally, I can easily imagine sending a file to someone to open with an older version and it causing
friction where it could be easily avoided. And it even made testing a bit more difficult because
I wanted to compare opening the same file with the patched and un-patched version. But if there
is no hard requirement I can't really put too much pressure to not remove it.

> Thanks a lot for the reviewing and testing!
> Leo
> 

  reply	other threads:[~2021-04-15 14:50 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-12  9:10 [PATCH v4 0/6] perf arm-spe: Enable timestamp Leo Yan
2021-04-12  9:10 ` [PATCH v4 1/6] perf arm-spe: Remove unused enum value ARM_SPE_PER_CPU_MMAPS Leo Yan
2021-04-15 14:13   ` James Clark
2021-04-15 14:41     ` Leo Yan
2021-04-15 14:49       ` James Clark [this message]
2021-04-12  9:10 ` [PATCH v4 2/6] perf arm-spe: Save clock parameters from TIME_CONV event Leo Yan
2021-04-12  9:10 ` [PATCH v4 3/6] perf arm-spe: Convert event kernel time to counter value Leo Yan
2021-04-12  9:10 ` [PATCH v4 4/6] perf arm-spe: Assign kernel time to synthesized event Leo Yan
2021-04-15 14:46   ` James Clark
2021-04-15 15:23     ` Leo Yan
2021-04-16 12:51       ` James Clark
2021-04-16 13:21         ` Leo Yan
2021-04-29 15:23         ` Leo Yan
2021-04-12  9:10 ` [PATCH v4 5/6] perf arm-spe: Bail out if the trace is later than perf event Leo Yan
2021-04-12  9:10 ` [PATCH v4 6/6] perf arm-spe: Don't wait for PERF_RECORD_EXIT event Leo Yan
2021-04-15 14:43 ` [PATCH v4 0/6] perf arm-spe: Enable timestamp James Clark
2021-04-15 14:56   ` Leo Yan

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=a3a516c5-fc13-50d6-d80f-66f68d1c89c1@arm.com \
    --to=james.clark@arm.com \
    --cc=Al.Grant@arm.com \
    --cc=Dave.Martin@arm.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=john.garry@huawei.com \
    --cc=jolsa@redhat.com \
    --cc=leo.yan@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mathieu.poirier@linaro.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).