From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752209AbcIBIeZ (ORCPT ); Fri, 2 Sep 2016 04:34:25 -0400 Received: from merlin.infradead.org ([205.233.59.134]:51216 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750979AbcIBIeY (ORCPT ); Fri, 2 Sep 2016 04:34:24 -0400 Date: Fri, 2 Sep 2016 10:33:38 +0200 From: Peter Zijlstra To: Stephane Eranian Cc: Jiri Olsa , Vegard Nossum , Thomas Gleixner , Vince Weaver , Ingo Molnar , David Carrillo-Cisneros , "H. Peter Anvin" , Kan Liang , Arnaldo Carvalho de Melo , Paul Turner , Linus Torvalds , LKML , Alexander Shishkin , "linux-tip-commits@vger.kernel.org" Subject: Re: [tip:perf/core] perf/core: Check return value of the perf_event_read() IPI Message-ID: <20160902083338.GK10138@twins.programming.kicks-ass.net> References: <1471467307-61171-2-git-send-email-davidcc@google.com> <20160822071737.GF4349@krava> <20160822082932.GA13171@krava> <20160822103823.GA2271@krava> <20160829100309.GS10121@twins.programming.kicks-ass.net> <20160829130213.GF10168@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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..