Re: [PATCH RFC 3/7] perf jevents: Add support for a system events PMU

From: Jiri Olsa <jolsa@redhat.com>
To: John Garry <john.garry@huawei.com>
Cc: peterz@infradead.org, mingo@redhat.com, acme@kernel.org,
	mark.rutland@arm.com, alexander.shishkin@linux.intel.com,
	namhyung@kernel.org, will@kernel.org, ak@linux.intel.com,
	linuxarm@huawei.com, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, suzuki.poulose@arm.com,
	james.clark@arm.com, zhangshaokun@hisilicon.com,
	robin.murphy@arm.com
Subject: Re: [PATCH RFC 3/7] perf jevents: Add support for a system events PMU
Date: Tue, 11 Feb 2020 15:46:51 +0100	[thread overview]
Message-ID: <20200211144651.GD93194@krava> (raw)
In-Reply-To: <b148f0b6-d2ae-6520-8da1-7aed2c9e1d6b@huawei.com>

On Mon, Feb 10, 2020 at 03:55:00PM +0000, John Garry wrote:
> On 10/02/2020 12:07, Jiri Olsa wrote:
> > On Fri, Jan 24, 2020 at 10:35:01PM +0800, John Garry wrote:
> > 
> > SNIP
> > 
> > >   	- Set of 'PMU events tables' for all known CPUs in the architecture,
> > > @@ -83,11 +93,11 @@ NOTES:
> > >   	2. The 'pmu-events.h' has an extern declaration for the mapping table
> > >   	   and the generated 'pmu-events.c' defines this table.
> > > -	3. _All_ known CPU tables for architecture are included in the perf
> > > -	   binary.
> > > +	3. _All_ known CPU and system tables for architecture are included in
> > > +	   the perf binary.
> > > -At run time, perf determines the actual CPU it is running on, finds the
> > > -matching events table and builds aliases for those events. This allows
> > > +At run time, perf determines the actual CPU or system it is running on, finds
> > > +the matching events table and builds aliases for those events. This allows
> > >   users to specify events by their name:
> > >   	$ perf stat -e pm_1plus_ppc_cmpl sleep 1
> > > @@ -150,3 +160,18 @@ where:
> > >   	i.e the three CPU models use the JSON files (i.e PMU events) listed
> > >   	in the directory 'tools/perf/pmu-events/arch/x86/silvermont'.
> > > +
> > > +The mapfile_sys.csv format is slightly different, in that it contains a SYSID
> > > +instead of the CPUID:
> > > +
> > > +	Header line
> > > +	SYSID,Version,Dir/path/name,Type
> > 
> 
> Hi jirka,
> 
> > can't we just add prefix to SYSID types? like:
> > 
> > 	SYSID-HIP08,v1,hisilicon/hip08/sys,sys
> > 	0x00000000480fd010,v1,hisilicon/hip08/cpu,core
> > 	0x00000000500f0000,v1,ampere/emag,core
> > 
> > because the rest of the line is the same, right?
> 
> I did consider that already. It should be workable.
> 
> > 
> > seems to me that having one mapfile type would be less confusing
> 
> I thought that having it all in a single file would be more confusing :)

hum, I think that if we keep it separated like:

	SYSID-HIP08,v1,hisilicon/hip08/sys,sys
	SYSID-krava,v1,hisilicon/krava/sys,sys
	0x00000000480fd010,v1,hisilicon/hip08/cpu,core
	0x00000000500f0000,v1,ampere/emag,core

then we should be fine.. not too many humans read that file anyway ;-)

jirka