Messages in this thread | | | Subject | Re: [BUG] perf_event: semantic of PERF_SAMPLE_READ unclear | From | Peter Zijlstra <> | Date | Fri, 26 Aug 2011 14:13:01 +0200 |
| |
On Fri, 2011-08-26 at 14:02 +0200, Stephane Eranian wrote: > On Thu, Aug 25, 2011 at 7:32 PM, Peter Zijlstra <peterz@infradead.org> wrote: > > On Thu, 2011-08-25 at 19:19 +0200, Stephane Eranian wrote: > >> But the difficulty is that > >> we cannot grab any locks, not sure we need one given the call path. > > > > Nah we should be able to simply iterate all siblings and update them > > in-place, since its group members they should all be co-scheduled. The > > only difficulty is cross pmu group members.. > > > Are we allowing event from different PMU to be in the same event group? > If so, is that useful?
We allow software events, which can always be scheduled, to be part of a hardware group. We don't allow mixing of different hardware pmus.
Allowing a software event is useful if for example the hardware pmu doesn't have a sampling interrupt.
| |