Message-ID: <20120821155908.GA5499@gmail.com>
Date:	Tue, 21 Aug 2012 17:59:08 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Matthew Garrett <mjg@...hat.com>
Cc:	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


* Matthew Garrett <mjg@...hat.com> wrote:

> On Tue, Aug 21, 2012 at 05:19:10PM +0200, Ingo Molnar wrote:
> > * Matthew Garrett <mjg59@...f.ucam.org> wrote:
> > > [...] AC/battery is just not an important power management 
> > > policy input when compared to various other things.
> > 
> > Such as?
> 
> The scheduler's behaviour is going to have a minimal impact on 
> power consumption on laptops. Other things are much more 
> important - backlight level, ASPM state, that kind of thing. 
> So why special case the scheduler? [...]

I'm not special casing the scheduler - but we are talking about 
scheduler policies here, so *if* it makes sense to handle this 
dynamically then obviously the scheduler wants to use system 
state information when/if the kernel can get it.

Your argument is as if you said that the shape of a car's side 
view mirrors is not important to its top speed, because the 
overall shape of the chassis and engine power are much more 
important.

But we are desiging side view mirrors here, so we might as well 
do a good job there.

> [...] This is going to be hugely more important on 
> multi-socket systems, where your policy is usually going to be 
> dictated by the specific workload that you're running at the 
> time. [...]

If only we had some kernel subsystem that is intimiately familar 
with the workloads running on the system and could act 
accordingly and with low latency.

We could name that subsystem it in some intuitive fashion: it 
switches and schedules workloads, so how about calling it the 
'scheduler'?

> [...] The exception is in cases where your rack is 
> overcommitted for power and your rack management unit is 
> telling you to reduce power consumption since otherwise it's 
> going to have to cut the power to one of the machines in the 
> rack in the next few seconds.

( That must be some ACPI middleware driven crap, right? Not 
  really the Linux kernel's problem. )

> > The thing is, when I use Linux on a laptop then AC/battery 
> > is *the* main policy input.
> 
> And it's already well handled from userspace, as it has to be.

Not according to the developers switching away from Linux 
desktop distros in droves, because MacOSX or Win7 has 30%+ 
better battery efficiency.

The scheduler might be a small part of the picture, but it's 
certainly a part of it.

> > > Userspace has been doing a perfectly reasonable job of 
> > > determining policy here.
> > 
> > Has it properly switched the scheduler's balancing between 
> > power-effient and performance-maximizing strategies when for 
> > example a laptop's AC got unplugged/replugged?
> 
> No, because sched_mt_powersave usually crippled performance 
> more than it saved power and nobody makes multi-socket 
> laptops.

That's a user-space policy management fail right there: why 
wasn't this fixed? If the default policy is in the kernel we can 
at least fix it in one place for the most common cases. If it's 
spread out amongst multiple projects then progress only happens 
at glacial speed ...

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/

Powered by blists - more mailing lists