On Thu, 2010-01-21 at 11:21 +0100, Stephane Eranian wrote: > Are you suggesting a speculative approach where you first try simply > accumulate then schedule and if this fails, then restart the whole > loop but this time adding and scheduling each event individually? > For groups, you'd have to fail the group if one of its events fails.
No, I'm only talking about groups. The complaint from frederic was that current hw_perf_group_sched_in() implementations have to basically replicate all of the group_sched_in() and event_sched_in() stuff, which seems wasteful. So I was thinking of an alternative interface that would give the same end result but not as much code replication. I'm now leaning towards adding a parameter to ->enable() to postpone schedulability and add a hw_perf_validate() like call. With that I'm also looking at what would be the sanest way to multiplex all the current weak hw_perf* functions in the light of multiple pmu implementations. ------------------------------------------------------------------------------ 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
