Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935246AbcKNRhq (ORCPT ); Mon, 14 Nov 2016 12:37:46 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:37624 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932705AbcKNRhn (ORCPT ); Mon, 14 Nov 2016 12:37:43 -0500 Date: Mon, 14 Nov 2016 18:37:33 +0100 From: Peter Zijlstra To: Josh Triplett Cc: "Paul E. McKenney" , linux-kernel@vger.kernel.org, mingo@kernel.org, jiangshanlai@gmail.com, dipankar@in.ibm.com, akpm@linux-foundation.org, mathieu.desnoyers@efficios.com, tglx@linutronix.de, rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com, dvhart@linux.intel.com, fweisbec@gmail.com, oleg@redhat.com, bobby.prani@gmail.com Subject: Re: [PATCH tip/core/rcu 6/7] rcu: Make expedited grace periods recheck dyntick idle state Message-ID: <20161114173733.GJ3142@twins.programming.kicks-ass.net> References: <20161114165648.GA15216@linux.vnet.ibm.com> <1479142633-15315-6-git-send-email-paulmck@linux.vnet.ibm.com> <20161114172512.bcwdy66elesds5t4@jtriplet-mobl2.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161114172512.bcwdy66elesds5t4@jtriplet-mobl2.jf.intel.com> 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 Content-Length: 955 Lines: 17 On Mon, Nov 14, 2016 at 09:25:12AM -0800, Josh Triplett wrote: > On Mon, Nov 14, 2016 at 08:57:12AM -0800, Paul E. McKenney wrote: > > Expedited grace periods check dyntick-idle state, and avoid sending > > IPIs to idle CPUs, including those running guest OSes, and, on NOHZ_FULL > > kernels, nohz_full CPUs. However, the kernel has been observed checking > > a CPU while it was non-idle, but sending the IPI after it has gone > > idle. This commit therefore rechecks idle state immediately before > > sending the IPI, refraining from IPIing CPUs that have since gone idle. > > > > Reported-by: Rik van Riel > > Signed-off-by: Paul E. McKenney > > atomic_add_return(0, ...) seems odd. Do you actually want that, rather > than atomic_read(...)? If so, can you please document exactly why? Yes that is weird. The only effective difference is that it would do a load-exclusive instead of a regular load.