On Fri, Oct 10, 2014 at 01:02:02PM +0100, Matt Fleming wrote: > On Wed, 08 Oct, at 04:49:57PM, Peter Zijlstra wrote: > > > > The thing is, with multiplexing you cannot fail at event creation time > > anyhow. The only time where you can 'fail' is when programming the PMU, > > when its full its full. > > > > Those that don't fit, get to wait their turn. > > For CQM it's not about "fitting" everything in the PMU but more about > monitoring the same thing (task, cgroup) with different events, i.e. one > thing with two RMIDs. We have the RMID recycling algorithm to make > things fit, but that doesn't help us out here. > > An example scenario that isn't supported by this patch series is > monitoring a cgroup while simultaneously monitoring a task that's part > of that cgroup. Whichever event is created second will fail at event > init time.
That was what I had that conflict thing for, ISTR seeing some parts of that here. > And that seemed like a fair approach to me. But the more I think about > it, the more I begin to agree that maybe we should allow users the > flexibility to create conflicting events, particularly because there > appears to be precedent in other parts of perf. Yeah, although typically its not this hard. CQM is 'interesting' because its so different. > Hmm... "rotation" is starting to become my least favourite word. :-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
