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..
