On Fri, Jan 23, 2015 at 03:22:57PM +0000, Mark Rutland wrote: > > > It seems this would still allow you to group CPU-affine software and > > > uncore events, which also doesn't make sense: the software events will > > > count on a single CPU while the uncore events aren't really CPU-affine. > > > > > > Which isn't anything against this patch, but probably something we > > > should tighten up too. > > > > Indeed, that would need a wee bit of extra infrastructure though; as we > > cannot currently distinguish between regular cpuctx and uncore like > > things. > > Isn't the event->pmu->task_ctx_nr sufficient, as with how we identify > software events? > > Or am I making some completely bogus assumptions in the diff below?
> /* > + * System-wide (A.K.A. "uncore") events cannot be associated with a > + * particular CPU, and hence cannot be associated with a particular > + * task either. It's non-sensical to group them with other event types, > + * which are CPU or task bound. > + */ So I think we want to allow grouping software events with say uncore events; if you start them both out on the same 'cpu' perf_pmu_migrate_context() would move the software event along with it. The use case is for non-sampling uncores, where if you have a software leader you can still get a periodic samples. Clearly looking at task state or the like is pointless, but PERF_SAMPLE_READ is useful to record values at regular intervals into the buffer. But yes, I think ctx_nr might just do. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
