linux-kernel - Re: [PATCH RFC 0/4] Scheduler idle notifiers and users

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:	Tue, 21 Feb 2012 13:56:22 +0100
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Pantelis Antoniou <panto@...oniou-consulting.com>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	Saravana Kannan <skannan@...eaurora.org>,
	Ingo Molnar <mingo@...e.hu>, linaro-kernel@...ts.linaro.org,
	Nicolas Pitre <nico@...xnic.net>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Oleg Nesterov <oleg@...hat.com>, cpufreq@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Anton Vorontsov <anton.vorontsov@...aro.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Mike Chan <mike@...roid.com>, Dave Jones <davej@...hat.com>,
	Todd Poynor <toddpoynor@...gle.com>, kernel-team@...roid.com,
	linux-arm-kernel@...ts.infradead.org,
	Arjan Van De Ven <arjan@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH RFC 0/4] Scheduler idle notifiers and users

On Tue, 2012-02-21 at 14:38 +0200, Pantelis Antoniou wrote:
> 
> If we go to all the trouble of integrating cpufreq/cpuidle/sched into scheduler
> callbacks, we should place hooks into the thermal framework/PM as well.
> 
> It will pretty common to have per core temperature readings, on most
> modern SoCs. 
> 
> It is quite conceivable to have a case with a multi-core CPU where due
> to load imbalance, one (or more) of the cores is running at full speed
> while the rest are mostly idle. What you want do, for best performance
> and conceivably better power consumption, is not to throttle either 
> frequency or lowers voltage to the overloaded CPU but to migrate the
> load to one of the cooler CPUs.
> 
> This affects CPU capacity immediately, i.e. you shouldn't schedule more
> load on a CPU that its too hot, since you'll only end up triggering thermal 
> shutdown. The ideal solution would be to round robin
> the load from the hot CPU to the cooler ones, but not so fast that we lose
> due to the migration of state from one CPU to the other.
> 
> In a nutshell, the processing capacity of a core is not static, i.e. it
> might degrade over time due to the increase of temperature caused by the
> previous load.
> 
> What do you think? 

This is called core-hopping, and yes that's a nice goal, although I
would like to do that after we get the 'simple' bits up and running. I
suspect it'll end up being slightly more complex than we'd like to due
to the fact that the goal conflicts with wanting to aggregate things on
cpu0 due to cpu0 being special for a host of reasons.


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