All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Garry <john.garry@huawei.com>
To: Jiri Olsa <jolsa@redhat.com>, <will.deacon@arm.com>
Cc: <peterz@infradead.org>, <mingo@redhat.com>, <acme@kernel.org>,
	<alexander.shishkin@linux.intel.com>, <namhyung@kernel.org>,
	<ak@linux.intel.com>, <wcohen@redhat.com>,
	<ganapatrao.kulkarni@cavium.com>, <catalin.marinas@arm.com>,
	<mark.rutland@arm.com>, <xuwei5@hisilicon.com>,
	<linuxarm@huawei.com>, <zhangshaokun@hisilicon.com>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 2/5] perf jevents: add support for arch recommended events
Date: Mon, 11 Dec 2017 10:25:10 +0000	[thread overview]
Message-ID: <aacbb0f9-cd5c-00c1-4ca8-36548fcb87bd@huawei.com> (raw)
In-Reply-To: <20171209073104.GB14297@krava>

On 09/12/2017 07:31, Jiri Olsa wrote:
> On Fri, Dec 08, 2017 at 03:42:10PM +0000, John Garry wrote:
>> On 08/12/2017 12:29, Jiri Olsa wrote:
>>> On Wed, Dec 06, 2017 at 03:20:14PM +0000, John Garry wrote:
>>>> On 06/12/2017 13:36, Jiri Olsa wrote:
>>>>> On Wed, Dec 06, 2017 at 12:13:16AM +0800, John Garry wrote:
>>>>>> For some architectures (like arm64), there are architecture-
>>>>>> defined recommended events. Vendors may not be obliged to
>>>>>> follow the recommendation and may implement their own pmu
>>>>>> event for a specific event code.
>>>>>>
>>>>>> This patch adds support for parsing events from arch-defined
>>>>>> recommended JSONs, and then fixing up vendor events when
>>>>>> they have implemented these events as recommended.
>>>>>
>>>>> in the previous patch you added the vendor support, so
>>>>> you have arch|vendor|platform key for the event list
>>>>> and perf have the most current/local event list
>>>>>
>>>>> why would you need to fix it? if there's new event list,
>>>>> the table gets updated, perf is rebuilt.. I'm clearly
>>>>> missing something ;-)
>>>>
>>>> The 2 patches are quite separate. In the first patch, I just added support
>>>> for the vendor subdirectory.
>>>>
>>>> So this patch is not related to rebuilding when adding a new event list or
>>>> dependency checking.
>>>>
>>>> Here we are trying to allow the vendor to just specify that an event is
>>>> supported as standard in their platform, without duplicating all the
>>>> standard event fields in their JSON. When processing the vendor JSONs, the
>>>> jevents tool can figure which events are standard and create the proper
>>>> event entries in the pmu events table, referencing the architecture JSON.
>>>
>>
>> Hi jirka,
>>
>>> I think we should keep this simple and mangle this with some pointer logic
>
> sry for confusion, of course it should have been '.. and NOT mangle..' ;-)
>
>>>
>>> now you have arch/vendor/platform directory structure..
>>
>> I'm glad that there seems to be no objection to this, as I feel that this
>> was a problem.
>>
>> why don't
>>> you add events for every such directory? I understand there will
>>> be duplications, but we already have them for other archs and it's
>>> not big deal:
>>
>> The amount of duplication was the concern. As mentioned earlier, it would be
>> anticipated that every vendor would implement these events as recommended,
>> so a copy for every platform from every vendor. We're looking for a way to
>> avoid this.
>>
>> Actually having a scalable JSON standard format for pmu events, which allows
>> us to define common events per architecture / vendor and reference them per
>> platform JSON could be useful.
>>
>> Here we're dealing with trade-off between duplication (simplicity) vs
>> complexity (or over-engineering).
>
> understood, but as I said we already are ok with duplicates,
> if it's reasonable size as is for x86 now..  how much amount
> are we talking about for arm?
>

Hi jirka,

These JSONs would only apply to vendors which have custom ARMv8 
implementations. If you check the ARMv8 ARM, there's 10 such companies 
recorded as ARMv8 implementators.

So this means that in the future we could have tens to hundreds of JSONs 
for arm64, all with these duplicated events.

At this point I'll ask Will Deacon to share his thoughts, as he 
originally requested this feature.

Thanks,
John

> jirka
>
> .
>

WARNING: multiple messages have this Message-ID (diff)
From: john.garry@huawei.com (John Garry)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 2/5] perf jevents: add support for arch recommended events
Date: Mon, 11 Dec 2017 10:25:10 +0000	[thread overview]
Message-ID: <aacbb0f9-cd5c-00c1-4ca8-36548fcb87bd@huawei.com> (raw)
In-Reply-To: <20171209073104.GB14297@krava>

On 09/12/2017 07:31, Jiri Olsa wrote:
> On Fri, Dec 08, 2017 at 03:42:10PM +0000, John Garry wrote:
>> On 08/12/2017 12:29, Jiri Olsa wrote:
>>> On Wed, Dec 06, 2017 at 03:20:14PM +0000, John Garry wrote:
>>>> On 06/12/2017 13:36, Jiri Olsa wrote:
>>>>> On Wed, Dec 06, 2017 at 12:13:16AM +0800, John Garry wrote:
>>>>>> For some architectures (like arm64), there are architecture-
>>>>>> defined recommended events. Vendors may not be obliged to
>>>>>> follow the recommendation and may implement their own pmu
>>>>>> event for a specific event code.
>>>>>>
>>>>>> This patch adds support for parsing events from arch-defined
>>>>>> recommended JSONs, and then fixing up vendor events when
>>>>>> they have implemented these events as recommended.
>>>>>
>>>>> in the previous patch you added the vendor support, so
>>>>> you have arch|vendor|platform key for the event list
>>>>> and perf have the most current/local event list
>>>>>
>>>>> why would you need to fix it? if there's new event list,
>>>>> the table gets updated, perf is rebuilt.. I'm clearly
>>>>> missing something ;-)
>>>>
>>>> The 2 patches are quite separate. In the first patch, I just added support
>>>> for the vendor subdirectory.
>>>>
>>>> So this patch is not related to rebuilding when adding a new event list or
>>>> dependency checking.
>>>>
>>>> Here we are trying to allow the vendor to just specify that an event is
>>>> supported as standard in their platform, without duplicating all the
>>>> standard event fields in their JSON. When processing the vendor JSONs, the
>>>> jevents tool can figure which events are standard and create the proper
>>>> event entries in the pmu events table, referencing the architecture JSON.
>>>
>>
>> Hi jirka,
>>
>>> I think we should keep this simple and mangle this with some pointer logic
>
> sry for confusion, of course it should have been '.. and NOT mangle..' ;-)
>
>>>
>>> now you have arch/vendor/platform directory structure..
>>
>> I'm glad that there seems to be no objection to this, as I feel that this
>> was a problem.
>>
>> why don't
>>> you add events for every such directory? I understand there will
>>> be duplications, but we already have them for other archs and it's
>>> not big deal:
>>
>> The amount of duplication was the concern. As mentioned earlier, it would be
>> anticipated that every vendor would implement these events as recommended,
>> so a copy for every platform from every vendor. We're looking for a way to
>> avoid this.
>>
>> Actually having a scalable JSON standard format for pmu events, which allows
>> us to define common events per architecture / vendor and reference them per
>> platform JSON could be useful.
>>
>> Here we're dealing with trade-off between duplication (simplicity) vs
>> complexity (or over-engineering).
>
> understood, but as I said we already are ok with duplicates,
> if it's reasonable size as is for x86 now..  how much amount
> are we talking about for arm?
>

Hi jirka,

These JSONs would only apply to vendors which have custom ARMv8 
implementations. If you check the ARMv8 ARM, there's 10 such companies 
recorded as ARMv8 implementators.

So this means that in the future we could have tens to hundreds of JSONs 
for arm64, all with these duplicated events.

At this point I'll ask Will Deacon to share his thoughts, as he 
originally requested this feature.

Thanks,
John

> jirka
>
> .
>

  reply	other threads:[~2017-12-11 10:27 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-05 16:13 [RFC PATCH 0/5] perf events patches for improved ARM64 support John Garry
2017-12-05 16:13 ` John Garry
2017-12-05 16:13 ` [RFC PATCH 1/5] perf jevents: add support for pmu events vendor subdirectory John Garry
2017-12-05 16:13   ` John Garry
2017-12-06 13:38   ` Jiri Olsa
2017-12-06 13:38     ` Jiri Olsa
2017-12-06 14:41     ` John Garry
2017-12-06 14:41       ` John Garry
2017-12-05 16:13 ` [RFC PATCH 2/5] perf jevents: add support for arch recommended events John Garry
2017-12-05 16:13   ` John Garry
2017-12-05 17:27   ` Andi Kleen
2017-12-05 17:27     ` Andi Kleen
2017-12-06  8:34     ` John Garry
2017-12-06  8:34       ` John Garry
2017-12-06 13:36   ` Jiri Olsa
2017-12-06 13:36     ` Jiri Olsa
2017-12-06 15:20     ` John Garry
2017-12-06 15:20       ` John Garry
2017-12-08 12:29       ` Jiri Olsa
2017-12-08 12:29         ` Jiri Olsa
2017-12-08 15:42         ` John Garry
2017-12-08 15:42           ` John Garry
2017-12-09  7:31           ` Jiri Olsa
2017-12-09  7:31             ` Jiri Olsa
2017-12-11 10:25             ` John Garry [this message]
2017-12-11 10:25               ` John Garry
2017-12-15 11:22             ` John Garry
2017-12-15 11:22               ` John Garry
2017-12-16 18:47               ` Andi Kleen
2017-12-16 18:47                 ` Andi Kleen
2018-01-02 12:07                 ` John Garry
2018-01-02 12:07                   ` John Garry
2018-01-02 17:48                   ` Andi Kleen
2018-01-02 17:48                     ` Andi Kleen
2018-01-03 12:22                     ` John Garry
2018-01-03 12:22                       ` John Garry
2017-12-21 19:39               ` Jiri Olsa
2017-12-21 19:39                 ` Jiri Olsa
2018-01-04 17:17                 ` John Garry
2018-01-04 17:17                   ` John Garry
2018-01-08 14:08                   ` Jiri Olsa
2018-01-08 14:08                     ` Jiri Olsa
2017-12-06 13:37   ` Jiri Olsa
2017-12-06 13:37     ` Jiri Olsa
2017-12-06 14:40     ` John Garry
2017-12-06 14:40       ` John Garry
2017-12-08 12:31       ` Jiri Olsa
2017-12-08 12:31         ` Jiri Olsa
2017-12-08 15:38         ` John Garry
2017-12-08 15:38           ` John Garry
2017-12-09  7:26           ` Jiri Olsa
2017-12-09  7:26             ` Jiri Olsa
2017-12-05 16:13 ` [RFC PATCH 3/5] perf vendor events arm64: add armv8 recommended events JSON John Garry
2017-12-05 16:13   ` John Garry
2017-12-05 16:13 ` [RFC PATCH 4/5] perf vendor events arm64: relocate thunderx2 JSON John Garry
2017-12-05 16:13   ` John Garry
2017-12-05 16:13 ` [RFC PATCH 5/5] perf vendor events arm64: add HiSilicon hip08 JSON John Garry
2017-12-05 16:13   ` John Garry
2017-12-06 16:42 ` [RFC PATCH 0/5] perf events patches for improved ARM64 support William Cohen
2017-12-06 16:42   ` William Cohen
2017-12-06 17:35   ` John Garry
2017-12-06 17:35     ` John Garry

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=aacbb0f9-cd5c-00c1-4ca8-36548fcb87bd@huawei.com \
    --to=john.garry@huawei.com \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=catalin.marinas@arm.com \
    --cc=ganapatrao.kulkarni@cavium.com \
    --cc=jolsa@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=wcohen@redhat.com \
    --cc=will.deacon@arm.com \
    --cc=xuwei5@hisilicon.com \
    --cc=zhangshaokun@hisilicon.com \
    /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.