Re: [PATCH] a local-timer-free version of RCU

From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Joe Korty <joe.korty@ccur.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
	"mathieu.desnoyers@efficios.com" <mathieu.desnoyers@efficios.com>,
	"dhowells@redhat.com" <dhowells@redhat.com>,
	"loic.minier@linaro.org" <loic.minier@linaro.org>,
	"dhaval.giani@gmail.com" <dhaval.giani@gmail.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"josh@joshtriplett.org" <josh@joshtriplett.org>,
	Jim Houston <jim.houston@comcast.net>
Subject: Re: [PATCH] a local-timer-free version of RCU
Date: Mon, 8 Nov 2010 11:50:19 -0800	[thread overview]
Message-ID: <20101108195019.GD4032@linux.vnet.ibm.com> (raw)
In-Reply-To: <20101108151829.GB8996@tsunami.ccur.com>

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