From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754851AbbDOTRm (ORCPT ); Wed, 15 Apr 2015 15:17:42 -0400 Received: from mga03.intel.com ([134.134.136.65]:2971 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751300AbbDOTRf (ORCPT ); Wed, 15 Apr 2015 15:17:35 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,582,1422950400"; d="scan'208";a="556644820" Date: Wed, 15 Apr 2015 12:17:34 -0700 From: Andi Kleen To: Ingo Molnar Cc: Michael Ellerman , Sukadev Bhattiprolu , mingo@redhat.com, Jiri Olsa , Arnaldo Carvalho de Melo , peterz@infradead.org, namhyung@kernel.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Pekka Enberg , Arnaldo Carvalho de Melo , Peter Zijlstra , Thomas Gleixner , Linus Torvalds , Borislav Petkov Subject: Re: 'perf upgrade' (was: Re: [PATCH v9 00/11] Add support for JSON event files.) Message-ID: <20150415191734.GC15335@tassilo.jf.intel.com> References: <1428993665-2133-1-git-send-email-sukadev@linux.vnet.ibm.com> <20150414085541.GA30202@gmail.com> <1429010508.27414.1.camel@ellerman.id.au> <20150414125822.GA32761@gmail.com> <1429052004.10000.1.camel@ellerman.id.au> <20150415092557.GA14942@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150415092557.GA14942@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > My suggestion to resolve the technical objections and lift the NAK > would be: > > - to add the tables to the source code, in a more human readable > format and (optionally) structure the event names better into a > higher level hierarchy, than the humungous linear dumps with no > explanations that you propose - while still supporting the 'raw' > vendor event names you want to use, for those people who are used > to them. Trying to understand what you mean with high level hierarchy: Do you mean something like the oprofile event / unit mask split, with events having a default unit mask? This one actually works poorly for modern Intel systems, as unit masks can completely change the behavior, so there is not necessarily a direct relation between the name before the dot and the one after, or a concept of a "default" unit mask. Or do you mean someone creating a tree hierarchy of events to systematically debug some particular problem? I implemented this in my toplev tool here: https://github.com/andikleen/pmu-tools/wiki/toplev-manual http://github.com/andikleen/pmu-tools But it's quite complicated and cannot really be done portable in a full way without completely turning perf into an architecture specific tool (which I assume you're opposed to) Or just some sections grouping events into different topics? "branches", "caches", "execution" or somesuch. I think this could be done with the JSON format. Just add a new header. Print them as sections in perf list. Or do you mean something like the perf cache events tables? We already have those. But they cannot replace direct micro architectural specific events, as the cache event tables do not necessarily express everything a given micro architecture supports. And also there is a lot of documentation using the vendor event names, which the users then want to use. If it's something else please explain. > > - to pre-parse the event descriptions at build time - beyond the > speedup FWIW I just measured it and the overhead parse time for the haswell JSON file on my laptop is about 33ms. # with event map % time ./obj-perf/perf list > /dev/null real 0m0.045s user 0m0.041s sys 0m0.003s % export EVENTMAP=/dev/zero % time perf list > /dev/null real 0m0.011s user 0m0.004s sys 0m0.006s > - to upgrade perf as a whole unit: this helps not just your usecase > but many other usecases as well. With the downloader it actually automatically downloads any missing files, so the upgrading just works. -Andi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lists.ozlabs.org (Postfix) with ESMTP id C39E51A0BBE for ; Thu, 16 Apr 2015 05:17:37 +1000 (AEST) Date: Wed, 15 Apr 2015 12:17:34 -0700 From: Andi Kleen To: Ingo Molnar Subject: Re: 'perf upgrade' (was: Re: [PATCH v9 00/11] Add support for JSON event files.) Message-ID: <20150415191734.GC15335@tassilo.jf.intel.com> References: <1428993665-2133-1-git-send-email-sukadev@linux.vnet.ibm.com> <20150414085541.GA30202@gmail.com> <1429010508.27414.1.camel@ellerman.id.au> <20150414125822.GA32761@gmail.com> <1429052004.10000.1.camel@ellerman.id.au> <20150415092557.GA14942@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20150415092557.GA14942@gmail.com> Cc: Arnaldo Carvalho de Melo , Peter Zijlstra , peterz@infradead.org, linuxppc-dev@lists.ozlabs.org, Arnaldo Carvalho de Melo , linux-kernel@vger.kernel.org, Linus Torvalds , mingo@redhat.com, Borislav Petkov , namhyung@kernel.org, Thomas Gleixner , Sukadev Bhattiprolu , Jiri Olsa , Pekka Enberg List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , > My suggestion to resolve the technical objections and lift the NAK > would be: > > - to add the tables to the source code, in a more human readable > format and (optionally) structure the event names better into a > higher level hierarchy, than the humungous linear dumps with no > explanations that you propose - while still supporting the 'raw' > vendor event names you want to use, for those people who are used > to them. Trying to understand what you mean with high level hierarchy: Do you mean something like the oprofile event / unit mask split, with events having a default unit mask? This one actually works poorly for modern Intel systems, as unit masks can completely change the behavior, so there is not necessarily a direct relation between the name before the dot and the one after, or a concept of a "default" unit mask. Or do you mean someone creating a tree hierarchy of events to systematically debug some particular problem? I implemented this in my toplev tool here: https://github.com/andikleen/pmu-tools/wiki/toplev-manual http://github.com/andikleen/pmu-tools But it's quite complicated and cannot really be done portable in a full way without completely turning perf into an architecture specific tool (which I assume you're opposed to) Or just some sections grouping events into different topics? "branches", "caches", "execution" or somesuch. I think this could be done with the JSON format. Just add a new header. Print them as sections in perf list. Or do you mean something like the perf cache events tables? We already have those. But they cannot replace direct micro architectural specific events, as the cache event tables do not necessarily express everything a given micro architecture supports. And also there is a lot of documentation using the vendor event names, which the users then want to use. If it's something else please explain. > > - to pre-parse the event descriptions at build time - beyond the > speedup FWIW I just measured it and the overhead parse time for the haswell JSON file on my laptop is about 33ms. # with event map % time ./obj-perf/perf list > /dev/null real 0m0.045s user 0m0.041s sys 0m0.003s % export EVENTMAP=/dev/zero % time perf list > /dev/null real 0m0.011s user 0m0.004s sys 0m0.006s > - to upgrade perf as a whole unit: this helps not just your usecase > but many other usecases as well. With the downloader it actually automatically downloads any missing files, so the upgrading just works. -Andi