Messages in this thread | | | Date | Thu, 5 Jul 2012 20:46:48 -0700 | From | Josh Triplett <> | Subject | Re: [PATCH tip/core/rcu] Make RCU_FAST_NO_HZ respect nohz= boot parameter |
| |
On Thu, Jul 05, 2012 at 05:29:44PM -0700, Paul E. McKenney wrote: > On Thu, Jul 05, 2012 at 04:02:08PM -0700, Josh Triplett wrote: > > On Thu, Jul 05, 2012 at 03:37:31PM -0700, Paul E. McKenney wrote: > > > If the nohz= boot parameter disables nohz, then RCU_FAST_NO_HZ needs to > > > also disable itself. This commit therefore checks for tick_nohz_enabled > > > being zero, disabling rcu_prepare_for_idle() if so. This patch assumes > > > that tick_nohz_enabled can change at runtime: If this is not the case, > > > then a simpler approach suffices. > > > > Allowing nohz to change at runtime seems like an entirely unnecessary > > bit of added complexity. (So does having a boot parameter for it, but > > that one at least seems easier to handle.) > > I will let representatives from the various distros expound to you on > their one-binary-only strategy for kernel builds. ;-)
I'm aware. However, the subset of people wanting to turn off nohz seems sufficiently small at this point that I'd *hope* distro kernels could just always have it turned on. :)
In any case, as I said, the ability to change it at runtime seems like the primary bit of complexity; the ability to change it at boot time seems straightforward to handle.
> > What would the patch look like if you can assume nohz will never change > > at runtime? And does anyone have a use case for changing nohz at > > runtime, rather than at boot time? > > It would be a little bit simpler, but would break in very odd and > difficult-to-debug ways if anyone ever did allow it to change at runtime, > for example, to accommodate systems subject to varying workloads.
Granted, but it doesn't seem worth preemtively making RCU more complicated to accomodate a use case that nobody has said they have yet. :)
- Josh Triplett
| |