Re: perf_counter: request for three more sample data options

[Corey Ashford <cjashfor@linux.vnet.ibm.com>]

Thank you for your reply, Peter.

Peter Zijlstra wrote:
> On Thu, 2009-04-02 at 18:46 -0700, Corey Ashford wrote:
>> Currently, perf_counter has the ability to record the following on event 
>> counter overflow:
>>
>> Instruction Pointer
>> Call chain
>> Group counter values
>> Thread id
>>
>> To give perf_counter similar capabilities to perfmon2's default sampling 
>>   module, I'd like the following additional sample data to be added.
>>
>> Time stamp
> 
> Rather hard actually, to provide a decent timestamp from NMI context.
> 
>> CPU number
> 
> Could do I guess.
> 
>> Thread Group Id
> 
> As in the process id? PERF_RECORD_TID already provides that.
> 
>> I'd suggest the following
>>
>> enum perf_counter_record_format {
>>          PERF_RECORD_IP          = 1U << 0,
>>          PERF_RECORD_TID         = 1U << 1,
>>          PERF_RECORD_TGID        = 1U << 2,
>> -        PERF_RECORD_GROUP       = 1U << 2,
>> +        PERF_RECORD_GROUP       = 1U << 3,
>> -        PERF_RECORD_CALLCHAIN   = 1U << 3,
>> +        PERF_RECORD_CALLCHAIN   = 1U << 4,
>> +        PERF_RECORD_CPU_ID      = 1U << 5,
>> +        PERF_RECORD_TIMESTAMP   = 1U << 6,
>> };
>>
>> And of course the obvious changes to perf_event_type.
>>
>> I would expect that CPU ID would be 32 bits, and the timestamp to be the 
>> 64-bit current time.  TGID is the same size as TID.
> 
> Right, so PREF_RECORD_TID provides:
> 
>  { u32 pid, tid; }

Ah, I didn't know that.  Ok, that's only two things I want then :)

> 
> PERF_RECORD_TIMESTAMP would provide something like:
> 
>  { u64 time; }

Yep.

> 
> and per our u64 alignment rule, PERF_RECORD_CPU would provide
> 
>  { u64 cpuid; }
> 
> unless you can think of anything else to stuff in there?

We could leave the upper 32-bits reserved for now.  Perhaps someone 
later will come up with some nice info to put there.

> 
>> I am guessing the only difficult thing here would be obtaining the 
>> current time from an IRQ, especially NMI handler.  Is this difficult?
> 
> Yes, quite :-) I'll have to see what we can do there -- we could do a
> best effort thing with little to no guarantees I think.
> 

Best effort would be fine, I think.  I would assume that means that 
99.9% of the time, you'll get a correct timestamp, and the rest are 
rubbish?  Or would there be a way to detect when you're not able to give 
a correct timestamp and in that case replace the timestamp field with a 
special sentinel, like all hex f's?

Regards,

- Corey

Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
cjashfor@us.ibm.com