Re: [PATCH] perf_counter: extensible perf_counter_attr

Ingo Molnar
2009-06-09T11:54:18Z

* 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