From: Ingo Molnar <mingo@elte.hu>
To: Corey Ashford <cjashfor@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Paul Mackerras <paulus@samba.org>,
Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] perf_counter: extensible perf_counter_attr
Date: Tue, 9 Jun 2009 13:53:46 +0200 [thread overview]
Message-ID: <20090609115346.GB3062@elte.hu> (raw)
In-Reply-To: <4A2E19A9.3070201@linux.vnet.ibm.com>
* Corey Ashford <cjashfor@linux.vnet.ibm.com> wrote:
>> So 'arch dependent attributes' per se are bad and against the
>> perfcounters design. "Generic perfcounter feature only supported
>> by a single architecture initially" is better.
>
> Well, I think Intel has PEBS and AMD has some similar mechanism.
> I would guess that at some point you would want to provide access
> to those PMU features via these attributes. Since these
> mechanisms are very chip-specific, I don't think you would want to
> try to create an arch-independent interface to them. There may be
> future mechanisms that only make sense on one particular chip
> design, and would therefore not be a candidate for wider use, but
> would still make sense to provide some support for that mechanism
> via the attributes.
>
> Did you have some different plan for PEBS (etc.) ?
I think PEBS is best supported by a generic abstraction. Something
like this: it's basically a special sampling format, that generates
a record of:
struct pt_regs regs;
__u64 insn_latency; /* optional */
__u64 data_address; /* optional */
this is pretty generic.
The raw CPU records have a CPU specific format, and they have to be
demultiplexed anyway (on Nehalem, which can have up to four separate
PEBS counters - but each output into the same DS area), so the
lowlevel arch code converts the CPU record into the above generic
sample record when it copies it into the mmap pages. It's a quick
copy so no big deal performance-wise.
( Details:
- there might be some additional complications from sampling
32-bit contexts, but that too is a mostly low level detail that
gets hidden.
- we might use a tiny bit more compact registers structure than
struct pt_regs. OTOH it's a well-known structure so it makes
sense to standardize on it, even if the CPU doesnt sample all
registers.
)
Can you see desirable PEBS-alike PMU features that cannot be
expressed via such means?
Ingo
next prev parent reply other threads:[~2009-06-09 11:54 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-08 17:25 Peter Zijlstra
2009-06-08 19:02 ` Corey Ashford
2009-06-08 19:51 ` Peter Zijlstra
2009-06-08 21:18 ` Corey Ashford
2009-06-08 21:23 ` Peter Zijlstra
2009-06-08 21:29 ` Corey Ashford
2009-06-08 21:50 ` Ingo Molnar
2009-06-09 0:50 ` Corey Ashford
2009-06-09 6:51 ` Ingo Molnar
2009-06-09 8:13 ` Corey Ashford
2009-06-09 11:53 ` Ingo Molnar [this message]
2009-06-09 16:44 ` Corey Ashford
2009-06-09 22:00 ` Ingo Molnar
2009-06-09 23:16 ` Corey Ashford
2009-06-10 0:14 ` Paul Mackerras
2009-06-10 22:06 ` Corey Ashford
2009-06-09 4:17 ` Paul Mackerras
2009-06-09 6:53 ` Ingo Molnar
2009-06-09 9:58 ` Paul Mackerras
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=20090609115346.GB3062@elte.hu \
--to=mingo@elte.hu \
--cc=acme@ghostprotocols.net \
--cc=cjashfor@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/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
all inboxes | Powered by JetHome®