Messages in this thread | | | Date | Wed, 4 Feb 2015 13:59:54 +0100 | From | Peter Zijlstra <> | Subject | Re: [RFC][PATCH 1/3] perf: Tighten (and fix) the grouping condition |
| |
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.
| |