lkml.org 
[lkml]   [2006]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [-mm PATCH 1/4] RCU: split classic rcu
    On Mon, Sep 25, 2006 at 05:54:33PM +0100, Christoph Hellwig wrote:
    > On Sat, Sep 23, 2006 at 09:01:41PM +0530, Dipankar Sarma wrote:
    > >
    > > This patch re-organizes the RCU code to enable multiple implementations
    > > of RCU. Users of RCU continues to include rcupdate.h and the
    > > RCU interfaces remain the same. This is in preparation for
    > > subsequently merging the preepmtpible RCU implementation.
    >
    > I still disagree very strongly. In a given tree there should be oneRCU
    > implementation for the traditional interface. We probably want srcu
    > in addition, but not things hiding behind the interface.

    Hello, Christoph!

    I agree very much with your "oneRCU to defer them all" goal for the
    traditional interface.

    However, the current implementation is extremely well-tested and seems
    to be quite reliable. Yes, there might still be a rough edge or two
    in cases where people do call_rcu() in tight loops, but even that is
    being covered in most cases where "don't do that" doesn't apply (e.g.,
    close(open()) from user space). The Linux implementation of RCU is
    almost six years old, and first appeared in mainline almost four years
    ago -- that is some -serious- testing!

    We will be switching to a new implementation. I am working to make it
    as reliable as I know how, but it seems reasonable to have a changeover
    period that might be measured in years. I -really- don't want to be
    inflicting even the possibility of RCU implementation bugs on anyone who
    has not "signed up" for code that has not yet be hammered into total
    and complete submission! CONFIG_PREEMPT_RT is quite reliable even now,
    but there is "quite reliable" and then there is "hammered into total
    and complete submission". ;-)

    Also, we need any new implementation of RCU to be in a separate file.
    I don't want to even think about the number of times that I accidentally
    changed the wrong version of RCU when working on the -rt implementation
    before we split it -- the functions have the same name, right? :-/

    So maybe we rip the multi-RCU infrastructure out once we have fully
    (and I mean -fully-) tested the new RCU implementation, taken care of
    any performance anomalies, and so on. I would be totally OK with that,
    but believe the split will be needed in the meantime.

    Fair enough? Or am I missing something?

    Thanx, Paul
    -
    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/

    \
     
     \ /
      Last update: 2006-09-27 18:35    [W:0.024 / U:155.136 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site