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: <20151118154457.GD30184@e105550-lin.cambridge.arm.com>
Date:	Wed, 18 Nov 2015 15:44:59 +0000
From:	Morten Rasmussen <morten.rasmussen@....com>
To:	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>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	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 Fri, Nov 13, 2015 at 11:53:06AM -0800, Jacob Pan wrote:
> With increasingly constrained power and thermal budget, it's often
> necessary to cap power via throttling. Throttling individual CPUs
> or devices at random times can help power capping but may not be
> optimal in terms of energy efficiency. Frequency scaling is also
> limited by certain range before losing energy efficiency.
> 
> In general, the optimal solution in terms of energy efficiency is
> to align idle periods such that more shared circuits can be power
> gated to enter lower power states. Combined with energy efficient
> frequency point, idle injection provides a way to scale power and
> performance efficiently.
> 
> This patch introduces a scheduler based idle injection method, it
> works by blocking CFS runqueue synchronously and periodically. The
> actions on all online CPUs are orchestrated by per CPU hrtimers.

I fully agree with the idea of synchronous duty cycling of cpus for
thermal management to avoid those inefficient low frequencies where we
loose a lot of energy to static power consumption and get very little
work done. However, I would not necessarily want to punish all cpus
system-wide if we have local overheating in one corner. If would rather
have it apply to only the overheating socket in a multi-socket machine
and only the big cores in a big.LITTLE system.

Several people have already brought up that we should look into
integrating this with the thermal framework. It already has the concepts
of thermal zones and cooling devices which could be used to control
idle-injection separately for different sockets/clusters.

Also, letting user-space control idle-injection opens up for having two
entities (user-space daemon and the in-kernel thermal governor) stepping
on each others toes. Wouldn't the control of idle-injection naturally
belong to thermal governors so we have everything controlled from a
single place?
--
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/