Re: perf_counter: request for three more sample data options

[Corey Ashford]

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@xxxxxxxxxx

--
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/