On Mon, Jan 18, 2010 at 2:54 PM, Peter Zijlstra <pet...@infradead.org> 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. ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
