linux-kernel - Re: [RFC PATCH 3/3] 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]

Date:	Thu, 5 Nov 2015 07:28:50 -0800
From:	Arjan van de Ven <arjan@...ux.intel.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Jacob Pan <jacob.jun.pan@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Paul Turner <pjt@...gle.com>, Len Brown <len.brown@...el.com>,
	Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
	Tim Chen <tim.c.chen@...ux.intel.com>,
	Andi Kleen <andi.kleen@...el.com>,
	Rafael Wysocki <rafael.j.wysocki@...el.com>
Subject: Re: [RFC PATCH 3/3] sched: introduce synchronized idle injection

On 11/5/2015 6:33 AM, Peter Zijlstra wrote:
> On Thu, Nov 05, 2015 at 06:22:58AM -0800, Arjan van de Ven wrote:
>> On 11/5/2015 2:09 AM, Peter Zijlstra wrote:
>>
>>> I can see such a scheme having a fairly big impact on latency, esp. with
>>> forced idleness such as this. That's not going to be popular for many
>>> workloads.
>>
>> idle injection is a last ditch effort in thermal management, before
>> this gets used the hardware already has clamped you to a low frequency,
>> reduced memory speeds, probably dimmed your screen etc etc.
>>
>> at this point there are 3 choices
>> 1) Shut off the device
>> 2) do uncoordinated idle injection for 40% of the time
>> 3) do coordinated idle injection for 5% of the time
>>
>> as much as force injecting idle in a synchronized way sucks, the alternatives are worse.
>
> OK, it wasn't put that way. I figured it was a way to use less power on
> any workload with idle time on.

so idle injection (as with pretty much every thermal management feature) is NOT a way to save
on battery life. Every known method pretty much ends up sacrificing more in terms of performance
than you gain in instant power that over time you end up using more (drain battery basically).

idle injection, if synchronized, is one of the more effective ones, e.g. give up the least efficiency
compared to, say, unsynchronized or even inserting idle cycles in the CPU (T-states)...
not even speaking of just turning the system off.

>
> That said; what kind of devices are we talking about here; mobile with
> pittyful heat dissipation? Surely a well designed server or desktop
> class system should never get into this situation in the first place.

a well designed server may not, but the datacenter it is in may.
for example if the AC goes out, but also, sometimes the datacenter's peak heat dissapation
can exceed the AC capacity (which is outside temperature dependent.. yay global warming),
which may require an urgent reduction over a series of machines for the duration of the peak load/peak temperature
(usually just inserting a little bit, say 1%, over all servers will do)

>It just grates at me a bit that we have to touch hot paths for such
scenarios :/

well we have this as a driver right now that does not touch hot paths,
but it seems you and tglx also hate that approach with a passion....

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