Re: [tip:perf/core] perf/core: Check return value of the perf_event_read() IPI

[Peter Zijlstra <peterz@xxxxxxxxxxxxx>]

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


--
To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html