lkml.org 
[lkml]   [2009]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: perf_counter: request for three more sample data options
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



\
 
 \ /
  Last update: 2009-04-03 09:29    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site