Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754208Ab0KHTuY (ORCPT ); Mon, 8 Nov 2010 14:50:24 -0500 Received: from e6.ny.us.ibm.com ([32.97.182.146]:41589 "EHLO e6.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752503Ab0KHTuX (ORCPT ); Mon, 8 Nov 2010 14:50:23 -0500 Date: Mon, 8 Nov 2010 11:50:19 -0800 From: "Paul E. McKenney" To: Joe Korty Cc: Frederic Weisbecker , "mathieu.desnoyers@efficios.com" , "dhowells@redhat.com" , "loic.minier@linaro.org" , "dhaval.giani@gmail.com" , "tglx@linutronix.de" , "peterz@infradead.org" , "linux-kernel@vger.kernel.org" , "josh@joshtriplett.org" , Jim Houston Subject: Re: [PATCH] a local-timer-free version of RCU Message-ID: <20101108195019.GD4032@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20101104232148.GA28037@linux.vnet.ibm.com> <20101105210059.GA27317@tsunami.ccur.com> <20101106192812.GI15561@linux.vnet.ibm.com> <20101108150644.GB5466@nowhere> <20101108151829.GB8996@tsunami.ccur.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101108151829.GB8996@tsunami.ccur.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2518 Lines: 55 On Mon, Nov 08, 2010 at 10:18:29AM -0500, Joe Korty wrote: > On Mon, Nov 08, 2010 at 10:06:47AM -0500, Frederic Weisbecker wrote: > > On Sat, Nov 06, 2010 at 12:28:12PM -0700, Paul E. McKenney wrote: > >> OK, so your approach treats preempt_disable code sequences as RCU > >> read-side critical sections by relying on the fact that the per-CPU > >> ->krcud task cannot run until such code sequences complete, correct? > >> > >> This seems to require that each CPU's ->krcud task be awakened at > >> least once per grace period, but I might well be missing something. > > > > I understood it differently, but I might also be wrong as well. krcud > > executes the callbacks, but it is only woken up for CPUs that want to > > execute callbacks, not for those that only signal a quiescent state, > > which is only determined in two ways through rcu_poll_other_cpus(): > > > > - if the CPU is in an rcu_read_lock() critical section, it has the > > IN_RCU_READ_LOCK flag. If so then we set up its DO_RCU_COMPLETION flag so > > that it signals its quiescent state on rcu_read_unlock(). > > > > - otherwise it's in a quiescent state. > > > > This works for rcu and rcu bh critical sections. > > But this works in rcu sched critical sections only if rcu_read_lock_sched() has > > been called explicitly, otherwise that doesn't work (in preempt_disable(), > > local_irq_save(), etc...). I think this is what is not complete when > > Joe said it's not yet a complete rcu implementation. > > > > This is also the part that scaries me most :) > > Mostly, I meant that the new RCU API interfaces that have come into > existance since 2004 were only hastily wrapped or NOPed by me to get > things going. Ah, understood. > Jim's method only works with explicit rcu_read_lock..unlock sequences, > implicit sequences via preempt_disable..enable and the like are not > handled. I had thought all such sequences were converted to rcu_read_lock > but maybe that is not yet correct. Not yet, unfortunately. Having them all marked, for lockdep if nothing else, could be a big benefit. > Jim will have to comment on the full history. He is incommunicado > at the moment; hopefully he will be able to participate sometime in > the next few days. Sounds good! 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/