[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <e22a2fe2-051f-5395-9118-99617ffcab3d@huawei.com>
Date: Wed, 8 Dec 2021 12:30:46 +0000
From: John Garry <john.garry@...wei.com>
To: Andrew Kilroy <andrew.kilroy@....com>,
<linux-kernel@...r.kernel.org>, <linux-perf-users@...r.kernel.org>,
<acme@...nel.org>
CC: Will Deacon <will@...nel.org>,
Mathieu Poirier <mathieu.poirier@...aro.org>,
Leo Yan <leo.yan@...aro.org>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...hat.com>,
"Namhyung Kim" <namhyung@...nel.org>,
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 1/3] perf vendor events: For the Neoverse N2
On 07/12/2021 12:13, Andrew Kilroy wrote:
> On 07/12/2021 09:57, John Garry wrote:
>> On 03/12/2021 12:35, Andrew Kilroy wrote:
>>> Updates the common and microarch json file to add counters
>>> available in the Neoverse N2 chip, but should also apply to other ArmV8
>>> and ArmV9 cpus. Specified in ArmV8 architecture reference manual
>>>
>>> https://developer.arm.com/documentation/ddi0487/gb/?lang=en
>>>
>>> Some of the counters added to armv8-common-and-microarch.json are
>>> specified in the ArmV9 architecture reference manual supplement
>>> (issue A.a):
>>>
>>> https://developer.arm.com/documentation/ddi0608/aa
>>>
>>> The additional ArmV9 counters are
>>>
>>> TRB_WRAP
>>> TRCEXTOUT0
>>> TRCEXTOUT1
>>> TRCEXTOUT2
>>> TRCEXTOUT3
>>> CTI_TRIGOUT4
>>> CTI_TRIGOUT5
>>> CTI_TRIGOUT6
>>> CTI_TRIGOUT7
>>>
>>> This patch also adds files in pmu-events/arch/arm64/arm/neoverse-n2 for
>>> perf list to output the counter names in categories.
>>>
>>> A subsequent patch renames armv8-common-and-microarch.json and
>>> armv8-recommended.json to reflect that counters for armv9 are being
>>> added.
>>
>> This commentary should be in a cover letter. Please do that.
>>
>> And did you consider just adding a armv9-common-and-microarch.json and
>> armv9-recommended.json instead of adding to and renaming the v8 version?
>> I know that it creates scattered definitions, but we already have that in
>> dividing the common and the recommended JSONs.
>>
>
> I considered it, but I wasn't sure what was preferable. I thought I'd
> get some feedback. Do you consider the separation important? Any
> particular reason?
At the moment I don't think that it's a big issue. I just thought it
better to keep a structured and distinct file organisation by having
separate files. v9 stuff is quite new, so we can wait for other input here.
Thanks,
John
Powered by blists - more mailing lists