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

PERF_RECORD_TIMESTAMP would provide something like:

{ u64 time; }

and per our u64 alignment rule, PERF_RECORD_CPU would provide

{ u64 cpuid; }

unless you can think of anything else to stuff in 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.



\
 
 \ /
  Last update: 2009-04-03 09:03    [W:1.411 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site