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    [W:0.024 / U:33.888 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site