Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754269Ab3IIQRb (ORCPT ); Mon, 9 Sep 2013 12:17:31 -0400 Received: from e32.co.us.ibm.com ([32.97.110.150]:58848 "EHLO e32.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750990Ab3IIQRa (ORCPT ); Mon, 9 Sep 2013 12:17:30 -0400 Date: Mon, 9 Sep 2013 09:17:08 -0700 From: "Paul E. McKenney" To: Steven Rostedt Cc: Frederic Weisbecker , Peter Zijlstra , Eric Dumazet , linux-kernel@vger.kernel.org, mingo@elte.hu, laijs@cn.fujitsu.com, dipankar@in.ibm.com, akpm@linux-foundation.org, mathieu.desnoyers@efficios.com, josh@joshtriplett.org, niv@us.ibm.com, tglx@linutronix.de, dhowells@redhat.com, edumazet@google.com, darren@dvhart.com, sbw@mit.edu Subject: Re: [PATCH] rcu: Is it safe to enter an RCU read-side critical section? Message-ID: <20130909161708.GX3966@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20130909105347.GK31370@twins.programming.kicks-ass.net> <20130909121329.GA16280@somewhere> <20130909083926.3eceebef@gandalf.local.home> <20130909124547.GB16280@somewhere> <20130909085504.2ddd7e69@gandalf.local.home> <20130909130851.GC16280@somewhere> <20130909092142.05780991@gandalf.local.home> <20130909134505.GF16280@somewhere> <20130909135656.GT3966@linux.vnet.ibm.com> <20130909101629.32df27a2@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130909101629.32df27a2@gandalf.local.home> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13090916-0928-0000-0000-000001838F67 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2831 Lines: 62 On Mon, Sep 09, 2013 at 10:16:29AM -0400, Steven Rostedt wrote: > On Mon, 9 Sep 2013 06:56:56 -0700 > "Paul E. McKenney" wrote: > > > > Indeed, there is on ongoing naming debate as well. About the only point > > of agreement thus far is that the current names are inadequate. ;-) > > > > My current feeling is that rcu_is_cpu_idle() should be called > > rcu_watching_this_cpu() and what is called rcu_watching_this_cpu() > > in my local tree should be called __rcu_watching_this_cpu(). > > I disagree. Then it would not make sense if we take a return value of > "__rcu_watching_this_cpu()" and use it on another CPU to make other > decisions for that other CPU. Frederic and I both went through why this works. > I still think we are confusing concepts with implementation. Yes, the > RCU implementation tracks CPU state, but the concept is still based on > the task. You keep asserting this, but I am not seeing it. Sure, you can argue that grace periods are based on tasks as well as or instead of CPUs. But I am not convinced that it helps at the dynticks interface. > But you are right, with dynamic ticks, things get a little more > complex, as dynamic ticks is a CPU state, not a task state, as it can > be something other than the running task that changes the state > (another task gets scheduled on that CPU). > > But I think we are coupling RCU a bit too much with dynamic ticks here. > Maybe we need to take a step back to visualize concepts again. If we don't couple it pretty tightly, it won't work. And whatever we want to call this thing that determines what RCU is paying attention to has to be at the implementation level. For things like rcu_read_lock() and synchronize_rcu(), yes, the task view is important -- and in recent documentation is the POV I use. > The state of being in dynamic tick mode is determined by what a task or > tasks are doing on the CPU. One of those things is if the task needs to > be tracked by RCU. And here, is where I think we are getting our > confusion from. The dynamic tick state needs to check if the running > task is requiring RCU or not, and thus we ask for "is rcu needed on > this CPU?" when the real question is "is the task running on this CPU > requiring RCU?" > > Again, if we keep things in a conceptual mode, and not look too much at > the implementation details, I think more people will understand what's > going on. Especially those that don't know why something was > implemented the way it was. All this aside, do you have a name you are nominating? Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/