Messages in this thread | | | Date | Fri, 2 Sep 2016 10:33:38 +0200 | From | Peter Zijlstra <> | Subject | Re: [tip:perf/core] perf/core: Check return value of the perf_event_read() IPI |
| |
On Tue, Aug 30, 2016 at 09:26:18AM -0700, Stephane Eranian wrote: > I am trying to understand this better.
> There is a race between oncpu/active and the smp_call. By the time > you actually do the smp_call the oncpu may be wrong and smp_call now > returns an error given David's change.
> I suspect the race was always there.
Me too, I might even have done it on purpose and then forgot about it. Now cured with a comment.
> It boils down to what is the guarantee of the API in terms of the > "freshness" of the value returned on read(). I am guessing that if > you thought you had to do the smp_call, it is because the event was > still active and oncpu != -1.
> If it is no longer active, it happened very recently and, in that > case, one can use the saved count in the perf_event struct as a valid > value because it was necessarily updated when the event was scheduled > out.
Almost, if its not active, its not counting. Therefore we don't care about updates.
The other race, against sched_in(), is as you describe though, we can observe ACTIVE && on_cpu==-1 or INACTIVE && on_cpu (due to lack of ordering and serialization) but if we can observe that, the sched_in was (very) recent and we still don't care because its the same as if the read request happened slightly earlier etc..
| |