Messages in this thread | | | Date | Fri, 26 Aug 2011 14:08:07 +0200 | Subject | Re: [BUG] perf_event: semantic of PERF_SAMPLE_READ unclear | From | Stephane Eranian <> |
| |
Ok, forget what I said, I think the current code is fine.
perf_output_read_group() does call event->pmu->read() which calls x86_perf_event_update(). And this routine does read the actual counter. So you do get the latest version possible.
On Fri, Aug 26, 2011 at 2:02 PM, Stephane Eranian <eranian@google.com> 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? >
| |