[lkml]   [2006]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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 <>
    > >
    > >
    > > 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 :)

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-08-29 03:35    [W:0.022 / U:6.076 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site