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: <20151123095902.6a3af628@yairi>
Date:	Mon, 23 Nov 2015 09:59:02 -0800
From:	Jacob Pan <jacob.jun.pan@...ux.intel.com>
To:	Morten Rasmussen <morten.rasmussen@....com>
Cc:	Arjan van de Ven <arjan@...ux.intel.com>,
	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>, jacob.jun.pan@...ux.intel.com
Subject: Re: [PATCH 3/4] sched: introduce synchronized idle injection

On Thu, 19 Nov 2015 17:24:07 +0000
Morten Rasmussen <morten.rasmussen@....com> wrote:

> I could see this technique being useful within the SoC as well.
> Synchronized idle injection on all cpus in a cluster would allow us to
> reach cluster idle states where resources shared within the cluster
> can be gated or powered off as well. But yes, shutting down
> everything is more efficient if you are en serious trouble.
> 
> I was hoping this could be a good alternative to hotplugging cpus out
> for thermal management in non-critical situations, but it isn't that
> appealing if you have to throttle all the cpus. I would consider it an
> emergency-only mechanism (as in emergency brake) that isn't really
> suitable for normal thermal management. In which case: Does this sort
> of mechanism belong in the scheduler code?
I would think this is not an emergency-only mechanism. I know shutting
down all CPUs at the same time sounds bad but here are advantage of
having this in the scheduler in that we can still have certain QoS.
e.g. we yeild softirq, RT. etc. There are other workload info readily
available in the scheduler to better use this knob. e.g. sync with
other input timers such as media.

For normal thermal conditions, Skylake for example, the max efficient
frequency is ~900MHz. If thermal restriction happens (e.g. you want to
do fanless), would you like to lose energy efficiency by further
lowering frequency to 500Mhz? or do idle injection and take 5ms latency
for normal tasks? Idle injection gives you near linear
performance-power scaling.

Thanks,

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