From: Peter Zijlstra <peterz@infradead.org>
To: Robert Richter <robert.richter@amd.com>
Cc: "Stephane Eranian" <eranian@google.com>,
LKML <linux-kernel@vger.kernel.org>,
"Arnaldo Carvalho de Melo" <acme@redhat.com>,
mingo@elte.hu, "David Ahern" <dsahern@gmail.com>,
"Frédéric Weisbecker" <fweisbec@gmail.com>,
"Jiri Olsa" <jolsa@redhat.com>
Subject: Re: [BUG] perf stat: useless output for raw events with new event parser
Date: Thu, 26 Apr 2012 16:24:33 +0200 [thread overview]
Message-ID: <1335450273.13683.76.camel@twins> (raw)
In-Reply-To: <20120426131220.GB5046@erda.amd.com>
On Thu, 2012-04-26 at 15:12 +0200, Robert Richter wrote:
> On 26.04.12 12:27:11, Peter Zijlstra wrote:
> > Furthermore, once we have a common format, we could even ask Intel/AMD
> > (and other vendors) to provide their data in this format.
>
> I don't think that can be done with a reasonable effort.
I'm thinking you mis-understand, all we're talking about is a copy of
your event list (BKDG Fam 10h Rev 3.48, section 3.14) in a usable
format.
> Why not simply pass an identifier for each kind of pmu and then only
> add pmu specific code in userland? Much easier than all this sysfs
> format thing, where the kernel tries to tell userland what to do,
> which the kernel never can do exactly. And even if we can describe
> everything with sysfs, kernel and userland code becomes bloated, it
> actually is already, looking at the recent perf tool and kernel
> updates.
The format is only about encoding rules, it doesn't do constraints. All
it wants to convey is if you have an event-code of: 0x4E2 where to stick
it in perf_event_attr::config*. It doesn't want to tell you if that
event exists and if there's a particular umask that ought to go with it.
Its an aid to simplify constructing raw events, nothing more.
When I want to use funny events I'm staring at the Intel-SDM/AMD-BKDG
anyway and I find writing:
cpu/event=0x4e2,umask=0xf8/
A lot easier than:
r40000f8e2
because while I like numbers I cannot actually count and would get that
4 wrong half the time, furthermore I'd have to actually remember the
encoding rules; or something like:
cpu/event=L3_fills_caused_by_L2_evictions.modified_any_core/
Then again, some people are scared of numbers and prefer to wear down
their finger-tips writing silly names.
That said, a unique identifier in there might make sense, esp on things
like ARM that don't have CPUID and even if they do it doesn't actually
correlate to the PMU :-)
So I'd be perfectly ok with adding something
like /sys/bus/events/device/*/name or so.
next prev parent reply other threads:[~2012-04-26 14:24 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-23 10:45 [BUG] perf stat: useless output for raw events with new event parser Stephane Eranian
2012-04-23 10:48 ` Peter Zijlstra
2012-04-23 10:55 ` Jiri Olsa
2012-04-23 10:56 ` Robert Richter
2012-04-23 11:17 ` Stephane Eranian
2012-04-26 10:27 ` Peter Zijlstra
2012-04-26 12:53 ` Stephane Eranian
2012-04-26 14:03 ` Peter Zijlstra
2012-04-26 13:12 ` Robert Richter
2012-04-26 14:24 ` Peter Zijlstra [this message]
2012-04-26 14:45 ` Robert Richter
2012-04-26 15:39 ` Peter Zijlstra
2012-04-26 17:36 ` Robert Richter
2012-05-07 12:42 ` Peter Zijlstra
2012-05-07 16:58 ` Robert Richter
2012-04-23 10:57 ` Jiri Olsa
2012-05-02 11:14 ` Stephane Eranian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1335450273.13683.76.camel@twins \
--to=peterz@infradead.org \
--cc=acme@redhat.com \
--cc=dsahern@gmail.com \
--cc=eranian@google.com \
--cc=fweisbec@gmail.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=robert.richter@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox