Re: [PATCH 3/4] RCU: preemptible RCU implementation

[Dipankar Sarma]

On Mon, Aug 28, 2006 at 09:46:11PM +0100, Christoph Hellwig wrote:
> On Mon, Aug 28, 2006 at 09:42:22PM +0530, Dipankar Sarma wrote:
> > From: Paul McKenney <paulmck@xxxxxxxxxx>
> > http://www.rdrop.com/users/paulmck/RCU/OLSrtRCU.2006.08.11a.pdf
> > 
> > This patch was developed as a part of the -rt kernel
> > development and meant to provide better latencies when
> > read-side critical sections of RCU don't disable preemption.
> > As a consequence of keeping track of RCU readers, the readers
> > have a slight overhead (optimizations in the paper).
> > This implementation co-exists with the "classic" RCU
> > implementations and can be switched to at compiler.
> 
> NACK.  While a readers can sleep rcu version definitly has it's
> we should make it all or nothing.  Either we always gurantee that
> a rcu reader can sleep or never without external patches.  Having
> this a config option is the ultimate defeat for any kind of bug
> reproducabilility.

Good point. RCU users that want to sleep in the read-side
critical sections should be using *srcu APIs* which are separate
from RCU APIs - srcu_read_lock(), srcu_read_unlock(), synchronize_srcu().
I think of CONFIG_PREEMPT_RCU as similar to CONFIG_PREEMPT where
preemption is allowed in certain sections in the kernel code.
This makes even more sense once CONFIG_PREEMPT_RT is in
mainline in some form. I should perhaps put in explicit checks
to disallow people from sleeping in RCU read-side
critical sections.

> Please make the patch undconditional and see if it doesn't cause
> any significant slowdowns in production-like scenaries and then
> we can switch over to the readers can sleep variant unconditionally
> at some point.

It is still some way from getting there. It needs per-cpu callback
queues for which I am working on a patch. It also needs some
more of Paul's work to reduce read-side overheads. However,
it is reasonably useful in low-end SMP systems for workloads
requiring better scheduling latencies, so I see no reason
not to provide this for CONFIG_PREEMPT users. Besides,
this is one step forward towards merging "crazy" stuff from
-rt :)

Thanks
Dipankar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/