Re: [PATCH] perf_counter: extensible perf_counter_attr

[Ingo Molnar]

* Corey Ashford <cjashfor@xxxxxxxxxxxxxxxxxx> wrote:

> Thanks for your reply, Ingo.
>
> Ingo Molnar wrote:
>> 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.
>> )
>>
>>   
> I see, so that's how you'd return the data.  How would a user 
> specify that they want to use PEBS?

They wouldnt need to. PEBS would result in more precise samples when 
certain counters are used - and transparently so.

The non-PEBS NMI samples are pretty accurate to begin with, so it's 
not a _major_ difference in quality.

PEBS would also auto-activate when a user wants to sample say the 
instruction latency as well - and on non-PEBS hardware the platform 
code would refuse to open the counter.

PEBS could also be used to reduce the number of NMIs needed - so 
it's a transparent speedup as well.

> Another observation is that you'd need some sort of bit vector, or 
> at the least a document, that describes which registers are valid 
> in the pt_regs struct.

Initially i think we should use PEBS to transparently enhance 
regular IP samples.

What would we use the other registers for? Many registers will have 
stack context dependencies so the PEBS data cannot really be 
analyzed in any meaningful way after the fact.

(except perhaps for the narrow purpose of debugging)

>> Can you see desirable PEBS-alike PMU features that cannot be expressed 
>> via such means?
>
> Power PMU's provide some fairly complex features, such as a 
> thresholding mechanism which is used for marking instructions, and 
> also there's an Instruction Matching CAM which can be used to mark 
> only on certain instruction types.  Since these features are 
> present only on Power, I'm not sure it makes sense to go to the 
> trouble of abstracting them for use on other arch/chip designs.

Could you please describe the low level semantics more accurately - 
at least of the ones you find to be the most useful in practice?

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/