linux-kernel - Re: [PATCH] nohz1: Documentation

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Thu, 21 Mar 2013 19:01:01 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	paulmck@...ux.vnet.ibm.com, Rob Landley <rob@...dley.net>,
	linux-kernel@...r.kernel.org, josh@...htriplett.org,
	zhong@...ux.vnet.ibm.com, khilman@...aro.org, geoff@...radead.org,
	tglx@...utronix.de, Arjan van de Ven <arjan@...ux.intel.com>
Subject: Re: [PATCH] nohz1: Documentation

2013/3/21 Steven Rostedt <rostedt@...dmis.org>:
> [ Added Arjan in case he as anything to add about the idle=poll below ]
>
>
> On Wed, 2013-03-20 at 16:55 -0700, Paul E. McKenney wrote:
>> On Wed, Mar 20, 2013 at 07:32:18PM -0400, Steven Rostedt wrote:
>> > Not a comment on this document, but on the implementation. As idle NO_HZ
>> > can hurt RT, but RT would want to have full NO_HZ, it's a shame that you
>> > can't have both (no idle but full). As we only care about not letting
>> > the CPU go into deep sleep, I wonder if it wouldn't be too hard to add
>> > something that keeps idle from going into nohz mode. Hmm, I think there
>> > may be an option to keep the CPU from going too deep into sleep. That
>> > may be a better approach.
>>
>> Would the combination of CONFIG_NO_HZ=y, CONFIG_NO_HZ_FULL=y, and
>> idle=poll do the trick in this case?
>
> I'm not sure I would recommend idle=poll either. It would certainly
> work, but it goes to the other extreme. You think NO_HZ=n drains a
> battery? Try idle=poll.
>
> Looking at Documentation/kernel-parameters.txt, it looks like idle=mwait
> may be better. It states that performance is the same as idle=poll (if
> supported).
>
> Also there's a kernel parameter for x86 called intel_idle.max_cstate=X.
>
> As idle=poll will most likely run the processor very hot and you will
> need to add more electricity not only for the computer but also for the
> A/C, it would be nice to still have the CPU sleep, but just at a shallow
> (fast wakeup) state.
>
> Perhaps Arjan can add some input here?

But I note that it's an interesting usecase. May be we'll want to make
CONFIG_NO_HZ_FULL (or whatever it's going to be called) not depend on
CONFIG_NO_HZ_IDLE in the long.

We'll see.

Also, just a guess, but on dynticks-idle may be wakeup from deep CPU
sleep state is not the only latency source. Reprogramming the timer
tick on idle exit may be another one? Not sure how fast it is to write
to the clock device. I supect it's not that free. So probably you
would like to get rid of the entire dynticks-idle infrastructure for
real time.
--
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/