Messages in this thread | | | Date | Thu, 26 Feb 2009 04:09:33 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH] v4 Teach RCU that idle task is not quiscent state at boot |
| |
* Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
> 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 > systems. > > o Drop idle as a quiescent state, as is already the case for > rcupreempt. > > 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 > rcu_check_callbacks(). > > So I still like the flag check. Any alternatives that I am missing?
Indeed none of the alternatives looks particularly appealing, so i concur. Thanks Paul for analyzing it so thoroughly!
Ingo
| |