lkml.org 
[lkml]   [2016]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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..


\
 
 \ /
  Last update: 2016-09-17 09:58    [W:1.205 / U:0.548 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site