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 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) That way we know we need to track more state for rollback and can give the pmu implementation leeway to delay scheduling/availablility tests. 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? ------------------------------------------------------------------------------ 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
