On Mon, 2010-01-18 at 15:12 +0100, Stephane Eranian wrote: > > 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?
I'm not sure I understand your reply. Sure dropping hw_perf_group_sched_in() is still correct, but its also less optimal, since we have to determine schedulability for each incremental event. ------------------------------------------------------------------------------ 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
