linux-kernel - Re: [PATCH tip/core/rcu] Make RCU_FAST_NO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 6 Jul 2012 05:52:06 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Josh Triplett <josh@...htriplett.org>
Cc:	linux-kernel@...r.kernel.org, mingo@...e.hu, laijs@...fujitsu.com,
	dipankar@...ibm.com, akpm@...ux-foundation.org,
	mathieu.desnoyers@...icios.com, niv@...ibm.com, tglx@...utronix.de,
	peterz@...radead.org, rostedt@...dmis.org, Valdis.Kletnieks@...edu,
	dhowells@...hat.com, eric.dumazet@...il.com, darren@...art.com,
	fweisbec@...il.com, sbw@....edu, patches@...aro.org
Subject: Re: [PATCH tip/core/rcu] Make RCU_FAST_NO_HZ respect nohz= boot
 parameter

On Thu, Jul 05, 2012 at 08:46:48PM -0700, Josh Triplett wrote:
> 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. :)

The people who want it turned on are of course those who care deeply
about latency from idle, which appears to be a not-unimportant group.
My best guess is that a strong desire to switch this at runtime will
come from cloud-computing people who need to support those who care
deeply about latency from idle, but who want to conserve energy when
running other workloads.

> 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.

I would need to at least have a warning, which ends up retaining most
of the code.  Otherwise, my first notification of the change is "Hey,
we have this weird and difficult-to-reproduce slowdown (or even hang)."
Of course, this will be at a time when this section of code is the
absolute last thing on my mind...

> > > 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.
> :)

Speaking as the guy who repeatedly put off reducing RCU grace-period
initialization latency until someone actually complained about it,
despite my being quite certain from the get-go that someone was bound
to complain sooner or later, I can certainly appreciate and identify
with that sentiment.

But in the grace-period initialization latency case, the complexity
of the fix was large, and the problem-isolation procedure extremely
straightforward, courtesy of things like the latency tracer.
In constrast, in then case at hand, the incremental complexity is quite
small and the difficulty spotting the problem is likely to be quite large.

Hence my taking a different approach to these two situations.

							Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/