Messages in this thread | | | Date | Tue, 29 Aug 2006 07:03:14 +0530 | From | Dipankar Sarma <> | Subject | Re: [PATCH 3/4] RCU: preemptible RCU implementation |
| |
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@us.ibm.com> > > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |