Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752512AbdLKK1C (ORCPT ); Mon, 11 Dec 2017 05:27:02 -0500 Received: from szxga04-in.huawei.com ([45.249.212.190]:11925 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751281AbdLKK07 (ORCPT ); Mon, 11 Dec 2017 05:26:59 -0500 Subject: Re: [RFC PATCH 2/5] perf jevents: add support for arch recommended events To: Jiri Olsa , References: <1512490399-94107-1-git-send-email-john.garry@huawei.com> <1512490399-94107-3-git-send-email-john.garry@huawei.com> <20171206133607.GA12508@krava> <20171208122918.GE2799@krava> <20171209073104.GB14297@krava> CC: , , , , , , , , , , , , , , From: John Garry Message-ID: Date: Mon, 11 Dec 2017 10:25:10 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20171209073104.GB14297@krava> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.202.227.238] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5A2E5D21.0049,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 534993a3eeb0f86749f9e1e984a2db95 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3388 Lines: 90 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 > > . >