linux-kernel - Re: [RFC PATCH 2/5] perf jevents: add support for arch recommended events

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aacbb0f9-cd5c-00c1-4ca8-36548fcb87bd@huawei.com>
Date:   Mon, 11 Dec 2017 10:25:10 +0000
From:   John Garry <john.garry@...wei.com>
To:     Jiri Olsa <jolsa@...hat.com>, <will.deacon@....com>
CC:     <peterz@...radead.org>, <mingo@...hat.com>, <acme@...nel.org>,
        <alexander.shishkin@...ux.intel.com>, <namhyung@...nel.org>,
        <ak@...ux.intel.com>, <wcohen@...hat.com>,
        <ganapatrao.kulkarni@...ium.com>, <catalin.marinas@....com>,
        <mark.rutland@....com>, <xuwei5@...ilicon.com>,
        <linuxarm@...wei.com>, <zhangshaokun@...ilicon.com>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 2/5] perf jevents: add support for arch recommended
 events

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
>
> .
>