linux-kernel - Re: [discussion]sched: a rough proposal to enable power saving in scheduler

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: <20120822090304.GA23336@gmail.com>
Date:	Wed, 22 Aug 2012 11:03:04 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Alex Shi <alex.shi@...el.com>,
	Suresh Siddha <suresh.b.siddha@...el.com>,
	vincent.guittot@...aro.org, svaidy@...ux.vnet.ibm.com,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Paul Turner <pjt@...gle.com>
Subject: Re: [discussion]sched: a rough proposal to enable power saving in
 scheduler

* Alan Cox <alan@...rguk.ukuu.org.uk> wrote:

> > Why? Good scheduling is useful even in isolation.
> 
> For power - I suspect it's damn near irrelevant except on a 
> big big machine.

With deep enough C states it's rather relevant whether we 
continue to burn +50W for a couple of more milliseconds or not, 
and whether we have the right information from the scheduler and 
timer subsystem about how long the next idle period is expected 
to be and how bursty a given task is.

'Balance for energy efficiency' obviously ties into the C state 
and frequency selection logic, which is rather detached right 
now, running its own (imperfect) scheduling metrics logic and 
doing pretty much the worst possible C state and frequency 
decisions in typical everyday desktop workloads.

> Unless you've sorted out your SATA, fixed your phy handling, 
> optimised your desktop for wakeups and worked down the big 
> wakeup causes one by one it's turd polishing.
> 
> PM means fixing the stack top to bottom, and its a whackamole 
> game, each one you fix you find the next. You have to sort the 
> entire stack from desktop apps to kernel.

Moving 'policy' into user-space has been an utter failure, 
mostly because there's not a single project/subsystem 
responsible for getting a good result to users. This is why
I resist "policy should not be in the kernel" meme here.

> However benchmarks talk - so lets have some benchmarks ... on 
> a laptop.

Agreed.

Thanks,

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