lkml.org 
[lkml]   [2009]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: I.2 - Grouping
    From
    On Mon, Jun 22, 2009 at 1:50 PM, Ingo Molnar<mingo@elte.hu> wrote:
    >> 2/ Grouping
    >>
    >> By design, an event can only be part of one group at a time.

    As I read this again, another question came up. Is the statement
    above also true for the group leader?


    >> Events in a group are guaranteed to be active on the PMU at the
    >> same time. That means a group cannot have more events than there
    >> are available counters on the PMU. Tools may want to know the
    >> number of counters available in order to group their events
    >> accordingly, such that reliable ratios could be computed. It seems
    >> the only way to know this is by trial and error. This is not
    >> practical.
    >
    > Groups are there to support heavily constrained PMUs, and for them
    > this is the only way, as there is no simple linear expression for
    > how many counters one can load on the PMU.
    >
    But then, does that mean that users need to be aware of constraints
    to form groups. Group are formed by users. I thought, the whole point
    of the API was to hide that kind of hardware complexity.

    Groups are needed when sampling, e.g., PERF_SAMPLE_GROUP.
    For instance, I sample the IP and the values of the other events in
    my group. Grouping looks like the only way to sampling on Itanium
    branch buffers (BTB), for instance. You program an event in a generic
    counter which counts the number of entries recorded in the buffer.
    Thus, to sample the BTB, you sample on this event, when it overflows
    you grab the content of the BTB. Here, the event and the BTB are tied
    together. You cannot count the event in one group, and have the BTB
    in another one (BTB = 1 config reg + 32 data registers + 1 position reg).



    > The ideal model to tooling is relatively independent PMU registers
    > (counters) with little constraints - most modern CPUs meet that
    > model.
    >
    I agree that would be really good. But that's not what we have.

    > All the existing tooling (tools/perf/) operates on that model and
    > this leads to easy programmability and flexible results. This model
    > needs no grouping of counters.
    >
    > Could you please cite specific examples in terms of tools/perf/?
    > What feature do you think needs to know more about constraints? What
    > is the specific win in precision we could achieve via that?
    >
    See above example.


    \
     
     \ /
      Last update: 2009-06-22 21:47    [W:4.179 / U:0.452 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site