[lkml]   [2010]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] perf_events: improve x86 event scheduling (v5)
    On Mon, Jan 18, 2010 at 2:54 PM, Peter Zijlstra <> wrote:
    > On Mon, 2010-01-18 at 14:43 +0100, Frederic Weisbecker wrote:
    >> Shouldn't we actually use the core based pmu->enable(),disable()
    >> model called from kernel/perf_event.c:event_sched_in(),
    >> like every other events, where we can fill up the queue of hardware
    >> events to be scheduled, and then call a hw_check_constraints()
    >> when we finish a group scheduling?
    > Well the thing that makes hw_perf_group_sched_in() useful is that you
    > can add a bunch of events and not have to reschedule for each one, but
    > instead do a single schedule pass.
    That's right.

    > That said you do have a point, maybe we can express this particular
    > thing differently.. maybe a pre and post group call like:
    >  void hw_perf_group_sched_in_begin(struct pmu *pmu)
    >  int  hw_perf_group_sched_in_end(struct pmu *pmu)
    The issue with hw_perf_group_sched_in() is that because we do not know
    when we are done scheduling, we have to defer actual activation until
    hw_perf_enable(). But we have to still mark the events as ACTIVE,
    otherwise things go wrong in the generic layer and for non-PMU events.
    That leads to partial duplication of event_sched_in()/event_sched_out()
    in the PMU specific layer.

    As Frederic pointed out, the more natural way would be to simply rely
    on event_sched_in()/event_sched_out() and the rollback logic and just
    drop hw_perf_group_sched_in() which is there as an optimization and
    not for correctness. Scheduling can be done incrementally from the
    event_sched_in() function.

    > That way we know we need to track more state for rollback and can give
    > the pmu implementation leeway to delay scheduling/availablility tests.
    Rollback would still be handled by the generic code, wouldn't it?

    > Paul, would that work for you too?
    > Then there's still the question of having events of multiple hw pmus in
    > a single group, I'd be perfectly fine with saying that's not allowed,
    > what to others think?
    I have seen requests for measuring both core and uncore PMU events
    together for instance. It all depends on how uncore PMU will be managed.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2010-01-18 15:15    [W:0.022 / U:3.128 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site