All of lore.kernel.org
 help / color / mirror / Atom feed
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 17:39:32 +0200	[thread overview]
Message-ID: <1335454772.13683.101.camel@twins> (raw)
In-Reply-To: <20120426144514.GB18810@erda.amd.com>

On Thu, 2012-04-26 at 16:45 +0200, Robert Richter wrote:
> It is totally ok to have parser support for this. I simply do not see
> why we need to put the encoding into sysfs. We somehow know on which
> hardware we run and the parser should already know how to setup the
> syscall. So parsing the above finally ends in calling of something
> like:
> 
>  setup_event_for_some_pmu(event, 0x4e2, 0xf8);
> 
> We don't need any description of bit masks in sysfs for this. 

Its the kernel side decoding perf_event_attr, so it seems sensible to
also describe this encoding from the kernel.

Currently we mostly match the hardware encoding, but there's no strict
requirement to do so, we can already see some of that with the extra_reg
stuff, perf_event_attr::config1 can mean different things depending on
the event.

Keeping all this information in two places just seems like asking for it
to get out of sync.


  reply	other threads:[~2012-04-26 15:39 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
2012-04-26 14:45           ` Robert Richter
2012-04-26 15:39             ` Peter Zijlstra [this message]
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=1335454772.13683.101.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.