From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934210AbbJHRq4 (ORCPT ); Thu, 8 Oct 2015 13:46:56 -0400 Received: from e34.co.us.ibm.com ([32.97.110.152]:41807 "EHLO e34.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932847AbbJHRqy (ORCPT ); Thu, 8 Oct 2015 13:46:54 -0400 X-IBM-Helo: d03dlp02.boulder.ibm.com X-IBM-MailFrom: paulmck@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org Date: Thu, 8 Oct 2015 10:46:50 -0700 From: "Paul E. McKenney" To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, mingo@kernel.org, jiangshanlai@gmail.com, dipankar@in.ibm.com, akpm@linux-foundation.org, mathieu.desnoyers@efficios.com, josh@joshtriplett.org, 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 02/18] rcu: Move rcu_report_exp_rnp() to allow consolidation Message-ID: <20151008174650.GD3910@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <1444148977-14108-2-git-send-email-paulmck@linux.vnet.ibm.com> <20151006202937.GX3604@twins.programming.kicks-ass.net> <20151006205850.GW3910@linux.vnet.ibm.com> <20151007075114.GW2881@worktop.programming.kicks-ass.net> <20151007143325.GF3910@linux.vnet.ibm.com> <20151007144024.GI17308@twins.programming.kicks-ass.net> <20151007164858.GQ3910@linux.vnet.ibm.com> <20151008094933.GK3816@twins.programming.kicks-ass.net> <20151008153351.GC3910@linux.vnet.ibm.com> <20151008171203.GR3816@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151008171203.GR3816@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15100817-0017-0000-0000-00000E7CA709 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 08, 2015 at 07:12:03PM +0200, Peter Zijlstra wrote: > On Thu, Oct 08, 2015 at 08:33:51AM -0700, Paul E. McKenney wrote: > > > > > o CPU B therefore moves up the tree, acquiring the parent > > > > rcu_node structures' ->lock. In so doing, it forces full > > > > ordering against all prior RCU read-side critical sections > > > > of all CPUs corresponding to all leaf rcu_node structures > > > > subordinate to the current (non-leaf) rcu_node structure. > > > > > > And here we iterate the tree and get another lock var involved, here the > > > barrier upgrade will actually do something. > > > > Yep. And I am way too lazy to sort out exactly which acquisitions really > > truly need smp_mb__after_unlock_lock() and which don't. Besides, if I > > tried to sort it out, I would occasionally get it wrong, and this would be > > a real pain to debug. Therefore, I simply do smp_mb__after_unlock_lock() > > on all acquisitions of the rcu_node structures' ->lock fields. I can > > actually validate that! ;-) > > This is a whole different line of reasoning once again. > > The point remains, that the sole purpose of the barrier upgrade is for > the tree iteration, having some extra (pointless but harmless) instances > does not detract from that. > > > Fair enough, but I will be sticking to the simple coding rule that keeps > > RCU out of trouble! > > Note that there are rnp->lock acquires without the extra barrier though, > so you seem somewhat inconsistent with your own rule. > > See for example: > > rcu_dump_cpu_stacks() > print_other_cpu_stall() > print_cpu_stall() > > (did not do an exhaustive scan, there might be more) > > and yes, that is 'obvious' debug code and not critical to the correct > behaviour of the code, but it is a deviation from 'the rule'. Which I need to fix, thank you. Thanx, Paul