linux-kernel - Re: [RFC] [PATCH 1/1] perf: add support for arch-dependent symbolic event names to "perf stat"

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: <4B993AAF.9050507@linux.vnet.ibm.com>
Date:	Thu, 11 Mar 2010 10:47:11 -0800
From:	Corey Ashford <cjashfor@...ux.vnet.ibm.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [RFC] [PATCH 1/1] perf: add support for arch-dependent symbolic
 event names to "perf stat"

On 3/11/2010 4:46 AM, Ingo Molnar wrote:
[snip]
> If you want extensible events you can already do it by providing an ftrace
> tracepoint event via TRACE_EVENT. They are easy to add and ad-hoc, and are
> supported throughout by perf.

Is TRACE_EVENT an appropriate way to add hardware-specific counter events?  I 
will look into this.  Thanks for the pointer.

>
> That could be librarized further by providing an /eventfs or /proc/events
> interface to enumerate them.

We can enumerate events this way, but there are other aspects to events than 
just their names (see below).

>
> Or if you want to extend the perf events namespace ABI you can send patches
> for that as well. (It's not a big issue if a particular event is currently
> only supported on Power for example - as long as you make a good effort naming
> and structuring it in a reasonably generic way.)

I'm not sure how that would work.  The issue I am trying to solve here is that 
Power arch chips have a large number of very hardware-specific events that are 
not generalizable.  Many of these events not only have names, but other 
user-configurable bits as well that select or narrow the scope of which exact 
events are recorded.  This issue is dealt with nicely in libpfm4, as it has 
mechanisms for parsing event names and attributes (aka modifiers or unit masks), 
and then produces a usable config field for the perf_events_attr struct.

Should I take it from the above that you are completely against the idea of 
using an external library for hardware-specific event and attribute naming?

-- 
Regards,

- Corey

--
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/