On Thu, Apr 11, 2013 at 10:11:53AM -0700, Paul E. McKenney wrote: > On Thu, Apr 11, 2013 at 07:04:23PM +0200, Frederic Weisbecker wrote: > > On Thu, Apr 11, 2013 at 04:41:07PM +0000, Christoph Lameter wrote: > > > On Thu, 11 Apr 2013, Frederic Weisbecker wrote: > > > > > > > If there is no performance issue with that I'm all for it. > > > > > > Or have a > > > > > > CONFIG_LOWLATENCY > > > > > > that boots up a kernel with the proper configuration? > > > > It may be too general for a naming. But I don't mind just > > selecting CONFIG_RCU_NOCBS_ALL unconditionally. It's easily > > changed in the future if anybody complains. > > > > Btw, if CONFIG_RCU_NOCBS_ALL is set, the rcu_nocbs= parameter > > is ignored, right? If you want to keep that direction and not > > override the Kconfig choice, may be warn the user about that > > if the boot parameter is passed? > > Fair point. Let me think about how I should approach Thanx.
An alternative is to treat the Kconfig choice as a default setting that gets overriden by rcu_nocbs= This would require to refactor the three way Kconfig layout you've set, but that aligns with what Ingo is suggesting me to do with the full dynticks range: having CONFIG_NO_HZ_EXTENDED_ALL that is overriden by nohz_extended= if any (beware though, "extended" will soon be renamed to "full", lets hope it's our last take ;) That unifies both behaviours and it looks more flexible to me. Of course that means selecting CONFIG_RCU_NOCBS_ALL won't be enough for me to ensure my nohz range is also nocb, I'm fine with the cpumask check on boot though. Anyway, that's just a suggestion, the most important is that the user is informed of what's happening and how to deal with it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
