linux-kernel - Re: [RFC][PATCH 3/9] perf: export registerred pmus via sysfs

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <1273560419.5605.3426.camel@twins>
Date:	Tue, 11 May 2010 08:46:59 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Corey Ashford <cjashfor@...ux.vnet.ibm.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Lin Ming <ming.m.lin@...el.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	"eranian@...il.com" <eranian@...il.com>,
	"Gary.Mohr@...l.com" <Gary.Mohr@...l.com>,
	"arjan@...ux.intel.com" <arjan@...ux.intel.com>,
	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	Paul Mackerras <paulus@...ba.org>,
	"David S. Miller" <davem@...emloft.net>,
	Russell King <rmk+kernel@....linux.org.uk>,
	Paul Mundt <lethal@...ux-sh.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Will Deacon <will.deacon@....com>,
	Maynard Johnson <mpjohn@...ibm.com>,
	Carl Love <carll@...ibm.com>
Subject: Re: [RFC][PATCH 3/9] perf: export registerred pmus via sysfs

On Mon, 2010-05-10 at 16:13 -0700, Corey Ashford wrote:

> Having extra fields for each event would allow us to describe hardware-specific event attributes.  For example:
> /sys/devices/system/node/nodeN/node_events
>                                node_events/event_source_id
>                                node_events/local_misses/event_id
>                                           /local_hits/event_id
>                                           /crypto_datamover  <- specific node PMU
>                                               /marked_crb_rcv_des
>                                                   /event_id
>                                                   /attrib
>                                                          /lpid <- attribute name
>                                                          /lpid/type <- type of attribute (boolean, integer, etc.)
>                                                          /lpid/min  <- min value of int attribute
>                                                          /lpid/max  <- max value of int attribute
>                                                          /lpid/bit_offset <- amount to shift attribute value before OR'ing into the raw event code
>                                                          /marking_mode <- attribute name
>                                                          /marking_mode/type
>                                                          /...
> 
> Of course, these nodes would need to be replicated for each event that needs them or other attributes.

I would suggest having a 1:n pmu:event_source ratio, not the other way
around. So in your example above the crypto_datamover PMU thingy would
get its own event_source(s), which get placed at whatever place in the
machine topology they live. If that happens to be at the node level,
place them there.

> >> Sure, sounds like a sensible suggestion.
> >>
> >> One thing I'd also like to clarify is that !raw events should not be 
> >> exhaustive hardware event lists, those are best left for userspace, but 
> >> instead are generally useful events that can be expected to be implemented 
> >> by any hardware of that particular class.
> 
> Why exactly is this?  I got the impression this was something you and
> Ingo wanted earlier.  As big of an impact as it will be, it would be
> nice to unify the two event spaces (generic and raw) into one space
> that can be explored by a user space tool (or even crudely
> by /bin/ls).

No we want generic event spaces that have events that are generally
applicable to a whole class of PMUs, so say to all CPU PMUs, or all GPU
PMUs or all PCI-bridge PMUs.

What we do not want are exhaustive event lists for specific PMU
implementations, those are best left for userspace.

I'll let Ingo answer your other question.
--
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/