linux-kernel - Re: [PATCH 3/4] sched: introduce synchronized idle injection

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]

Message-ID: <564C88E7.4050907@linux.intel.com>
Date:	Wed, 18 Nov 2015 06:19:19 -0800
From:	Arjan van de Ven <arjan@...ux.intel.com>
To:	Ingo Molnar <mingo@...nel.org>,
	Jacob Pan <jacob.jun.pan@...ux.intel.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	John Stultz <john.stultz@...aro.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
	Len Brown <len.brown@...el.com>,
	Rafael Wysocki <rafael.j.wysocki@...el.com>,
	Eduardo Valentin <edubezval@...il.com>,
	Paul Turner <pjt@...gle.com>
Subject: Re: [PATCH 3/4] sched: introduce synchronized idle injection

On 11/18/2015 12:36 AM, Ingo Molnar wrote:
>
> What will such throttling do to latencies, as observed by user-space tasks? What's
> the typical expected frequency of the throttling frequency that you are targeting?

for this to meaningfully reduce power consumption, deep system power states need to be reached,
and for those to pay of, several milliseconds of idle are required.

for hard realtime stuff that is obviously insane, but I would assume that for those cases
your system is thermally fine. This only kicks in at the end of a "we're in thermal
problems" path, which can happen both on clients (thin devices) as well as servers
(airconditioning issues). The objective for this is to kick in before the
hardware built-in protections kick in (which are power off/reboot depending on a bunch of things).
The frequency of how often these 5 msec get injected depend on how deep the system
is in trouble; and is zero if the system is not in trouble.

The idea is that for the user it is better to inject several 5 msec intervals than it is
to inject one longer period.

You can compare this method to other ways of reducing thermal issues (like lowering cpu frequency),
and in a typical setup, this is done after the benign of those methods are exhausted.
Lowering frequency even lower is usually of a low efficiency (you need to lower the frequency a LOT
to gain a little bit of power in the bottom parts of the frequency ranges), while this idle will
not only put the CPU in low power, but will also put the system memory in low power and usually
a big chunk of the rest of the SOC. In many client systems, memory power consumption is higher than CPU
power consumption (and in big servers, it's also quite sizable), so there is a pretty hard
limit of how much you can do on thermals if you're not also kicking some of the memory power savings.
This means that to achieve a certain amount of reduction, the performance is impacted a lot less than
the more drastic methods you would need on the cpu side, if possible at all.
(stepping your 2 Ghz cpu down to 50Mhz may sound less evil than injecting 5msec of idle time, but in reality
that is impacting user tasks a heck of a lot more than 5msec of not being scheduled)

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