linux-kernel - Re: [PATCH v2 2/2] perf tools: Make Power7 events available for perf

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20130710023715.GC7491@concordia>
Date:	Wed, 10 Jul 2013 12:37:16 +1000
From:	Michael Ellerman <michael@...erman.id.au>
To:	Vince Weaver <vincent.weaver@...ne.edu>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Runzhen Wang <runzhen@...ux.vnet.ibm.com>,
	linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
	paulus@...ba.org, acme@...hat.com, mingo@...nel.org,
	Stephane Eranian <eranian@...gle.com>,
	sukadev@...ux.vnet.ibm.com, xiaoguangrong@...ux.vnet.ibm.com
Subject: Re: [PATCH v2 2/2] perf tools: Make Power7 events available for perf

On Tue, Jul 09, 2013 at 11:20:50AM -0400, Vince Weaver wrote:
> On Tue, 9 Jul 2013, Michael Ellerman wrote:
> 
> > On Mon, Jul 08, 2013 at 10:24:34PM -0400, Vince Weaver wrote:
> > > why is it a hack to use cpuid?
> > 
> > Because you're assuming that the PMU the kernel has exposed is for the
> > cpu you happen to be executing on.
> > 
> > But the real issue is with PMUs that are not in the CPU - there is no
> > easy way for userspace to detect them and determine which event list it
> > should be consulting.
> 
> what kind of devices are you talking about?  

GPUs, PCI host bridges, memory controllers, PCI attached accelerators,
strange devices on non standard buses, you name it.

> If they have kernel/perf_event support then they'd be putting a
> directory entry with a unique name into
> /sys/bus/event_source/devices/, right?

Yes. But although the name is unique it's not sufficient to actually
identify the list of events.

For example the CPU PMU is called "cpu" on most architectures, so userspace
needs to work out which exact CPU it is - and I know that's possible,
but it means the "simple little" event parsing library is not so simple
anymore.

Then imagine you have a GPU on PCI which registers its PMU as "gpu" -
how do you work out which GPU it is? Userspace can probably work it out
by trawling through sysfs and finding the vendor and device ids and
matching that with a lookup table. The library just got less simple
again.

Now say you have a PMU in your memory controller, it's not represented
in sysfs except for the PMU. Which memory controller is it? Maybe you
can infer it from the CPU you're on, but maybe you can't.

> > This whole thread is about making the event list not the kernel's job?
> 
> Yes.  This has been debated forever here; I'm firmly in the "event lists 
> should be entirely in userspace" camp but that's not the majority 
> position.

Yes we agree on the event list being in userspace, you can stop trying
to convince me.

What shouldn't be in userspace is the logic to detect which PMUs are
available on the system.

cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/