[lkml]   [2008]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] Performance Counters for Linux, v4
    On Mon, 2008-12-15 at 23:11 +1100, Paul Mackerras wrote:
    > Ingo Molnar writes:
    > > We are pleased to announce the v4 release of our performance counters
    > > subsystem implementation.
    > Looking at the code, I am wondering what you are planning to do to
    > support machines that have constraints on what sets of events can be
    > counted simultaneously. Currently you have the core code calling
    > counter->hw_ops->hw_perf_counter_enable which can't return an error.
    > The core expects it to be able to add any counter regardless of what
    > event it's counting, subject only to a maximum number of counters.
    > I assume you're going to change that.
    > I think the core should put together a list of counters and counter
    > groups that it would like to have on the PMU simultaneously and then
    > make one call to the arch layer to ask if that is possible. That
    > could either return success or failure. If it returns failure then
    > the core needs to ask for something less, or something different. I'm
    > not sure how the core should choose what to ask for instead, though.

    I think the constraint set should be applied when we add to a group, if
    when we add a counter to the group, the result isn't schedulable
    anymore, we should fail the group addition - and thereby the counter

    This would leave us with groups that are always schedulable in an atomic

    >From what I understand the code RRs groups (co-scheduling groups where
    possible) (ungrouped counter is a group of one), this means that with
    the above addition you'd have the needed control over things.

    If you need things to be atomic, create a single group, if you're fine
    with RR time-sharing, create multiple.

    This seems to leave a hole where multiple monitors collide and create
    multiple groups unaware of each-other - could we plug this hole with a
    group attribute?

     \ /
      Last update: 2008-12-16 15:25    [W:0.020 / U:20.528 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site