From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751935AbeADRS1 (ORCPT + 1 other); Thu, 4 Jan 2018 12:18:27 -0500 Received: from szxga04-in.huawei.com ([45.249.212.190]:3684 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751471AbeADRS0 (ORCPT ); Thu, 4 Jan 2018 12:18:26 -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> <5d322353-2785-a99f-bcd8-b948bd6cb09a@huawei.com> <20171221193917.GB1105@krava> CC: , , , , , , , , , , , , , , , From: John Garry Message-ID: <850a0774-9442-c836-f457-69e1e0d72fb2@huawei.com> Date: Thu, 4 Jan 2018 17:17:56 +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: <20171221193917.GB1105@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 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On 21/12/2017 19:39, Jiri Olsa wrote: >> Hi Jirka, >> > >> > When you say reasonable size for x86, I ran a string duplication finder on >> > the x86 JSONs and the results show a huge amount of duplication. Please >> > check this: >> > https://gist.githubusercontent.com/johnpgarry/68bc87e823ae2ce0f7b475b4e55e5795/raw/f4cea138999d8b34151b9586d733592e01774d7a/x86%2520JSON%2520duplication >> > >> > Extract: >> > "Found a 65 line (311 tokens) duplication in the following files: >> > Starting at line 100 of >> > /linux/tools/perf/pmu-events/arch/x86/ivybridge/ivb-metrics.json >> > Starting at line 100 of >> > /linux/tools/perf/pmu-events/arch/x86/ivytown/ivt-metrics.json >> > Starting at line 100 of >> > /linux/tools/perf/pmu-events/arch/x86/broadwell/bdw-metrics.json >> > Starting at line 100 of >> > /linux/tools/perf/pmu-events/arch/x86/skylakex/skx-metrics.json >> > Starting at line 76 of >> > /linux/tools/perf/pmu-events/arch/x86/jaketown/jkt-metrics.json >> > Starting at line 100 of >> > /linux/tools/perf/pmu-events/arch/x86/skylake/skl-metrics.json >> > Starting at line 76 of >> > /linux/tools/perf/pmu-events/arch/x86/sandybridge/snb-metrics.json >> > Starting at line 100 of >> > /linux/tools/perf/pmu-events/arch/x86/broadwellx/bdx-metrics.json" >> > Hi Jirka, Sorry for the slow reply. >> > Won't this all potentially have a big maintainence cost? > as Andi said it's mostly just the disk space, > which is not big deal > > I'm not doing JSON file updates, but I think having > simple single dir for platform/cpu could save us some > confusion in future Understood. But for ARM, which has very standardised architecture events, it is good to reduce this event duplication between platforms. > > however I won't oppose if you want to add this logic, > but please: > - use the list_head ;-) Of course > - leave the process_one_file function simple > and separate the level0 processing ok, this is how it should look already, albeit a couple of process_one_file() modifications. I'll re-check this. > - you are using 'EventCode' as an unique ID to find > the base, but it's not unique for x86, you'll need > to add some other ID scheme that fits to all archs Right, so you mentioned earlier using a new keyword token to identify whether we use the standard event, so we can go his way - ok? I would also like to mention at this point why I did the event pre-processing in jevents, and not a separate script: - current build does not transverse the arch tree - tree transversal for JSON processing is done in jevents - a script would mean derived objects, which means: - makefile changes for derived objects - jevents would have to deal with derived objects - jevents already has support for JSON processing The advantage of using a script is that we keep the JSON processing in jevents simple. All the best, John > > thanks, > jirka > From mboxrd@z Thu Jan 1 00:00:00 1970 From: john.garry@huawei.com (John Garry) Date: Thu, 4 Jan 2018 17:17:56 +0000 Subject: [RFC PATCH 2/5] perf jevents: add support for arch recommended events In-Reply-To: <20171221193917.GB1105@krava> 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> <5d322353-2785-a99f-bcd8-b948bd6cb09a@huawei.com> <20171221193917.GB1105@krava> Message-ID: <850a0774-9442-c836-f457-69e1e0d72fb2@huawei.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 21/12/2017 19:39, Jiri Olsa wrote: >> Hi Jirka, >> > >> > When you say reasonable size for x86, I ran a string duplication finder on >> > the x86 JSONs and the results show a huge amount of duplication. Please >> > check this: >> > https://gist.githubusercontent.com/johnpgarry/68bc87e823ae2ce0f7b475b4e55e5795/raw/f4cea138999d8b34151b9586d733592e01774d7a/x86%2520JSON%2520duplication >> > >> > Extract: >> > "Found a 65 line (311 tokens) duplication in the following files: >> > Starting at line 100 of >> > /linux/tools/perf/pmu-events/arch/x86/ivybridge/ivb-metrics.json >> > Starting at line 100 of >> > /linux/tools/perf/pmu-events/arch/x86/ivytown/ivt-metrics.json >> > Starting at line 100 of >> > /linux/tools/perf/pmu-events/arch/x86/broadwell/bdw-metrics.json >> > Starting at line 100 of >> > /linux/tools/perf/pmu-events/arch/x86/skylakex/skx-metrics.json >> > Starting at line 76 of >> > /linux/tools/perf/pmu-events/arch/x86/jaketown/jkt-metrics.json >> > Starting at line 100 of >> > /linux/tools/perf/pmu-events/arch/x86/skylake/skl-metrics.json >> > Starting at line 76 of >> > /linux/tools/perf/pmu-events/arch/x86/sandybridge/snb-metrics.json >> > Starting at line 100 of >> > /linux/tools/perf/pmu-events/arch/x86/broadwellx/bdx-metrics.json" >> > Hi Jirka, Sorry for the slow reply. >> > Won't this all potentially have a big maintainence cost? > as Andi said it's mostly just the disk space, > which is not big deal > > I'm not doing JSON file updates, but I think having > simple single dir for platform/cpu could save us some > confusion in future Understood. But for ARM, which has very standardised architecture events, it is good to reduce this event duplication between platforms. > > however I won't oppose if you want to add this logic, > but please: > - use the list_head ;-) Of course > - leave the process_one_file function simple > and separate the level0 processing ok, this is how it should look already, albeit a couple of process_one_file() modifications. I'll re-check this. > - you are using 'EventCode' as an unique ID to find > the base, but it's not unique for x86, you'll need > to add some other ID scheme that fits to all archs Right, so you mentioned earlier using a new keyword token to identify whether we use the standard event, so we can go his way - ok? I would also like to mention at this point why I did the event pre-processing in jevents, and not a separate script: - current build does not transverse the arch tree - tree transversal for JSON processing is done in jevents - a script would mean derived objects, which means: - makefile changes for derived objects - jevents would have to deal with derived objects - jevents already has support for JSON processing The advantage of using a script is that we keep the JSON processing in jevents simple. All the best, John > > thanks, > jirka >