Messages in this thread | | | Subject | Re: perf_counter: request for three more sample data options | From | Peter Zijlstra <> | Date | Fri, 03 Apr 2009 09:01:04 +0200 |
| |
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.
| |