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: <20100316093440.GE7961@elte.hu>
Date:	Tue, 16 Mar 2010 10:34:40 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Paul Mackerras <paulus@...ba.org>
Cc:	Corey Ashford <cjashfor@...ux.vnet.ibm.com>,
	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"


* Paul Mackerras <paulus@...ba.org> wrote:

> On Thu, Mar 11, 2010 at 01:46:08PM +0100, Ingo Molnar wrote:
> > 
> > * Corey Ashford <cjashfor@...ux.vnet.ibm.com> wrote:
> > 
> > > On 3/3/2010 6:30 PM, Corey Ashford wrote:
> > > >For your review, this patch adds support for arch-dependent symbolic
> > > >event names to the "perf stat" tool, and could be expanded to other
> > > >"perf *" commands fairly easily, I suspect.
> 
> > I'm quite much against stop-gap measures like this - they tend to become 
> > tomorrow's impossible-to-remove quirk.
> > 
> > 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.
> 
> If I've understood correctly what Corey is doing, I think you're missing the 
> point.  The idea, I thought, was to provide a way to be able to use symbolic 
> names for raw hardware events rather than just numbers.  I don't see how 
> ftrace tracepoint events are relevant to that.

tracepoints are relevant because they are the currently best way of how we 
assign symbolic names to various kernel-internal events. For ad-hoc usecases 
like this:

   http://dri.freedesktop.org/wiki/IntelPerformanceTuning

I'd much rather see that facility used (and, to the extent needed, extended) 
to provide support for rare arch events that we dont want to enumerate in a 
generic way.

Or, if the events are important enough to be hardcoded into the perf ABI 
itself, they should be generalized in a meaningful way - even if you dont 
expect them to show up on other CPUs.

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