[lkml]   [2008]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH, RFC] v7 scalable classic RCU implementation
    On Mon, Oct 27, 2008 at 08:48:00PM +0100, Manfred Spraul wrote:
    > Paul E. McKenney wrote:
    >> Agreed. Perhaps a good change to make while introducing stall detection
    >> to preemptable RCU -- there would then be three examples, which should
    >> allow good generalization.
    > Two implementations. IMHO the current rcu-classic code should be dropped
    > immediately when you add rcu-tree:
    > rcu-classic is buggy, as far as I can see long-running interrupts on nohz
    > cpus are not handled correctly. I don't think it makes sense to keep it in
    > the kernel in parallel to rcu-tree.
    > I would propose that rcu-tree replaces rcu-classic.
    > I'll continue to update rcu-state, I think that it will achieve lower
    > latency than rcu-tree [average/max time between call_rcu() and destruction
    > callback] and it doesn't have the irq disabled loop to find the missing
    > cpus.
    > If I find decent benchmarks where I can quantify the advantages, then I'll
    > propose to merge rcu-state as a third implementation in addition to
    > rcu-tree and rcu-preempt.
    > Paul: What do you think?

    In keeping with my reputation as a "conservative programmer", I would
    suggest that rcuclassic.c remain for a year or so. Distros branching
    off during this time should continue making rcuclassic.c be the default.
    Other uses should have rcutree.c as the default. At the end of the year,
    we remove rcuclassic.c.

    All that said, one attractive aspect of your suggestion is immediately
    removing rcuclassic.c would eliminate the need to do further work on it. ;-)

    Your benchmarking proposal for rcu-state makes sense to me.

    One other possible place for techniques from rcu-state may be in making
    preemptable RCU scale. This may take some time, as other parts of
    the RT kernel have their limitations, but sooner or later people are
    going to expect real-time response from even the largest machines.
    In addition, preemptable RCU has a number of shorter-term issues:

    1. RCU-boosting mechanism. (I need to combine the best of
    Steve's and my mechanisms. The treercu.c effort has been
    sort of a warm-up exercise for RCU-boosting.)

    2. Reducing the latency contribution of the preemptable RCU
    state machine (but note that moving this state machine out
    of the scheduling-clock irq handler means more stuff to boost).

    3. Porting the simpler dynticks interface from rcutree to
    preemptable RCU.

    4. Making the preemptable RCU tracing code use seqfile.

    Hmmm... Maybe it is (past) time for me to publish an RCU to-do list?

    Thanx, Paul

     \ /
      Last update: 2008-10-28 00:55    [W:0.024 / U:48.540 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site