linux-kernel - Re: [RFC v1] Tunable sched_mc_power

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <48663032.6010207@firstfloor.org>
Date:	Sat, 28 Jun 2008 14:36:02 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Matthew Garrett <mjg59@...f.ucam.org>
CC:	Peter Zijlstra <peterz@...radead.org>, dipankar@...ibm.com,
	balbir@...ux.vnet.ibm.com,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Suresh B Siddha <suresh.b.siddha@...el.com>,
	Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>,
	Ingo Molnar <mingo@...e.hu>, Vatsa <vatsa@...ux.vnet.ibm.com>,
	Gautham R Shenoy <ego@...ibm.com>
Subject: Re: [RFC v1] Tunable sched_mc_power_savings=n

Matthew Garrett wrote:
> On Fri, Jun 27, 2008 at 10:06:28AM +0200, Andi Kleen wrote:
> 
>> Ok distcc is a special case, but it doesn't apply to a lot of other
>> processes (do you really want your CPU to crank up for "updatedb" or
>> beagle or some backup job for example?)
> 
> If something's CPU-bound, then you almost certainly want to speed the 
> CPU up. There's no power advantage to leaving it at a low frequency. 

I'm not sure you can say it that certainly. While on many standalone systems
"race to idle" is the best strategy, there are cases where it is not
true.

For example if you're in a data center at a specific operating point and
you would need to crank up the air condition at significant power cost it might
be well better overall to force all servers to a lower operating point
and avoid that.

That said in general you all should have complained when ondemand behaviour
was introduced.

Also it's unclear that the general "race to idle" heuristic really
applies to the case of the "keep sockets idle" power optimization
that started this thread.

Usually package C states bring much more than core C states
and keeping another package completely idle saves likely
more power than the power cost of running something a little
bit slower on a package that is already busy on another core.

I still think using nice levels for this is reasonable.

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