mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®