Messages in this thread | | | Date | Mon, 8 Nov 2010 21:51:54 +0100 | From | Frederic Weisbecker <> | Subject | Re: [PATCH] a local-timer-free version of RCU |
| |
On Mon, Nov 08, 2010 at 11:49:04AM -0800, Paul E. McKenney wrote: > On Mon, Nov 08, 2010 at 04:06:47PM +0100, Frederic Weisbecker wrote: > > On Sat, Nov 06, 2010 at 12:28:12PM -0700, Paul E. McKenney wrote: > > > On Fri, Nov 05, 2010 at 05:00:59PM -0400, Joe Korty wrote: > > > > +/** > > > > + * synchronize_sched - block until all CPUs have exited any non-preemptive > > > > + * kernel code sequences. > > > > + * > > > > + * This means that all preempt_disable code sequences, including NMI and > > > > + * hardware-interrupt handlers, in progress on entry will have completed > > > > + * before this primitive returns. However, this does not guarantee that > > > > + * softirq handlers will have completed, since in some kernels > > > > > > 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. > > Unfortunately, local_irq_save() is allowed to stand in for > rcu_read_lock_bh(). :-/
Ah...right I missed that.
> > > 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 :) > > And if we can make all the the preempt_disable(), local_irq_disable(), ... > invoke rcu_read_lock(), then we have some chance of being able to dispense > with the IPIs to CPUs not having callbacks that need to be executed.
Right.
| |