[lkml]   [2009]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] v4 Teach RCU that idle task is not quiscent state at boot
    On Wed, Feb 25, 2009 at 05:00:24PM +0100, Ingo Molnar wrote:
    > * Paul E. McKenney <> wrote:
    > > +/* Internal to kernel, but needed by rcupreempt.h. */
    > > +extern int rcu_idle_cpu_truthful;
    > The name sucks a bit ;-) 'truthful' is an emotionally laden
    > statement and distracts from the technical purpose when reading
    > it ;)
    > Same for:
    > > +extern void rcu_idle_now_means_idle(void);

    I must confess that I was in fact a bit annoyed to learn that idle_cpu()
    telling me that a decidedly active CPU was idle. And if you think -these-
    names are emotionally laden, you should have seen my first choices. ;-)

    Nevertheless, point well taken. How about the following names instead?

    extern int rcu_scheduler_active;
    extern void rcu_scheduler_starting(void);

    > Also, i'm wondering, is there really no way to avoid this quirk.
    > We almost got away without it for a long time.

    A bit scary, isn't it? ;-)

    Looks to me that some RCU usage finally found its way into the early
    boot code path -- until that happened, no one needed to care what RCU
    mistakenly thought was happening with grace periods at early boot.

    I list some alternatives below.

    > This one:
    > > void rcu_check_callbacks(int cpu, int user)
    > > {
    > > if (user ||
    > > - (idle_cpu(cpu) && !in_softirq() &&
    > > - hardirq_count() <= (1 << HARDIRQ_SHIFT))) {
    > > + (idle_cpu(cpu) && rcu_idle_cpu_truthful &&
    > > + !in_softirq() && hardirq_count() <= (1 << HARDIRQ_SHIFT))) {
    > Is a hotpath called very often ...

    The "if" statement is indeed on the hotpath, but the additional check
    of rcu_idle_cpu_truthful is reached only if we didn't interrupt from
    user-mode execution and if the CPU is idle. So the only time anything
    is delayed by this extra check is when we take an interrupt from idle
    state, and then that interrupt handler is itself interrupted by the
    scheduling-clock interrupt.

    And of course, in the CONFIG_NO_HZ case, this code path is normally
    disabled entirely for an idle CPU.

    This therefore will not result in significant overhead, despite being
    in a hotpath.

    OK, alternatives...

    o Reverse the roles of the idle and init threads during startup,
    so that there is initially no idle thread.

    However, there appears to be a fair amount of code that assumes
    that there is always an idle thread.

    o As above, but create both the init and idle threads early so
    that there always is an idle thread that happens not to be
    running during boot.

    This would work, but seems to me to be uglier than the flag.

    o Stop using idle_cpu() in rcu_check_callbacks(), instead keeping
    a per-CPU "cpu_is_idle" variable that is set upon entry to the
    various idle() loops and cleared upon exit. It would be OK to
    take interrupts while "cpu_is_idle" is set.

    The disadvantage here is that there are quite a few idle loops,
    and it would be necessary to change them all. Missing one or
    two could result in indefinite grace periods on the affected

    o Drop idle as a quiescent state, as is already the case for

    This would result in indefinite grace-period delays for
    rcuclassic, but would actually work for rcutree. Except that
    it would cause rcutree to IPI each and every idle CPU for
    every grace period if !CONFIG_NO_HZ. I expect that this
    overhead would far exceed that of the extra flag check in

    So I still like the flag check. Any alternatives that I am missing?

    Thanx, Paul

     \ /
      Last update: 2009-02-25 18:19    [W:0.026 / U:24.496 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site