From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Ingo Molnar <mingo@kernel.org>
Cc: Arjan van de Ven <arjan@linux.intel.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Alex Shi <alex.shi@intel.com>,
Suresh Siddha <suresh.b.siddha@intel.com>,
vincent.guittot@linaro.org, svaidy@linux.vnet.ibm.com,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Paul Turner <pjt@google.com>
Subject: Re: [discussion]sched: a rough proposal to enable power saving in scheduler
Date: Tue, 21 Aug 2012 17:13:24 +0100 [thread overview]
Message-ID: <20120821161324.GA29665@srcf.ucam.org> (raw)
In-Reply-To: <20120821155908.GA5499@gmail.com>
On Tue, Aug 21, 2012 at 05:59:08PM +0200, Ingo Molnar wrote:
> * Matthew Garrett <mjg@redhat.com> wrote:
> > 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.
If the kernel is going to make power choices automatically then it
should do it everywhere, not piecemeal.
> > [...] 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 scheduler is unaware of whether I care about a process finishing
quickly or whether I care about it consuming less power.
> > [...] 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. )
It's as much the Linux kernel's problem as AC/battery decisions are -
ie, it's not.
> > > 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.
Ok so what you're actually telling me here is that you don't understand
anything about power management and where our problems are.
> The scheduler might be a small part of the picture, but it's
> certainly a part of it.
It's in the drivers, which is where it has been since we went tickless.
> > 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 ...
sched_mt_powersave was inherently going to have a huge impact on
performance, and with modern chips that would result in the platform
consuming more power. It was a feature that was useful for a small
number of generations of desktop CPUs - I don't think it would ever skew
the power/performance ratio in a useful direction on mobile hardware.
But feel free to blame userspace for hardware design.
--
Matthew Garrett | mjg59@srcf.ucam.org
next prev parent reply other threads:[~2012-08-21 16:13 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-13 12:21 [discussion]sched: a rough proposal to enable power saving in scheduler Alex Shi
2012-08-14 7:35 ` Alex Shi
2012-08-15 8:23 ` Peter Zijlstra
2012-08-15 11:05 ` Peter Zijlstra
2012-08-15 13:15 ` Borislav Petkov
2012-08-15 14:43 ` Peter Zijlstra
2012-08-16 3:22 ` Alex Shi
2012-08-16 3:09 ` Alex Shi
2012-08-15 13:45 ` Arjan van de Ven
2012-08-15 14:39 ` Peter Zijlstra
2012-08-15 14:43 ` Arjan van de Ven
2012-08-15 15:04 ` Peter Zijlstra
2012-08-15 17:59 ` Arjan van de Ven
2012-08-20 8:06 ` Ingo Molnar
2012-08-20 8:26 ` Peter Zijlstra
2012-08-20 13:26 ` Arjan van de Ven
2012-08-20 18:16 ` Matthew Garrett
2012-08-21 9:42 ` Ingo Molnar
2012-08-21 11:39 ` Matthew Garrett
2012-08-21 15:19 ` Ingo Molnar
2012-08-21 15:21 ` Arjan van de Ven
2012-08-21 15:28 ` Matthew Garrett
2012-08-21 15:59 ` Ingo Molnar
2012-08-21 16:13 ` Matthew Garrett [this message]
2012-08-21 18:23 ` Ingo Molnar
2012-08-21 18:34 ` Matthew Garrett
2012-08-22 9:10 ` Ingo Molnar
2012-08-22 11:35 ` Matthew Garrett
2012-08-23 8:19 ` Alex Shi
2012-08-21 18:52 ` Alan Cox
2012-08-22 9:03 ` Ingo Molnar
2012-08-22 11:00 ` Alan Cox
2012-08-22 11:33 ` Ingo Molnar
2012-08-22 12:58 ` Alan Cox
2012-08-21 16:02 ` Alan Cox
2012-08-22 5:41 ` Mike Galbraith
2012-08-22 13:02 ` Arjan van de Ven
2012-08-22 13:09 ` Mike Galbraith
2012-08-22 13:21 ` Matthew Garrett
2012-08-22 13:23 ` Arjan van de Ven
2012-08-16 1:14 ` Rik van Riel
2012-08-16 1:17 ` Arjan van de Ven
2012-08-16 1:21 ` Arjan van de Ven
2012-08-15 14:19 ` Arjan van de Ven
2012-08-15 14:44 ` Peter Zijlstra
2012-08-15 14:47 ` Thomas Gleixner
2012-08-15 16:23 ` Matthew Garrett
2012-08-15 16:34 ` Matthew Garrett
2012-08-15 18:02 ` Arjan van de Ven
2012-08-17 8:59 ` Paul Turner
2012-08-16 3:07 ` Alex Shi
2012-08-16 6:53 ` preeti
2012-08-16 9:58 ` Alex Shi
2012-08-16 12:45 ` Shilimkar, Santosh
2012-08-16 14:01 ` Arjan van de Ven
2012-08-16 18:45 ` Rik van Riel
2012-08-16 19:20 ` Arjan van de Ven
2012-08-17 1:29 ` Alex Shi
2012-08-17 18:41 ` Matthew Garrett
2012-08-17 18:44 ` Arjan van de Ven
2012-08-17 18:47 ` Matthew Garrett
2012-08-17 19:45 ` Chris Friesen
2012-08-17 19:50 ` Matthew Garrett
2012-08-17 20:16 ` Chris Friesen
2012-08-18 14:33 ` Luming Yu
2012-08-18 14:52 ` Arjan van de Ven
2012-08-16 14:31 ` Morten Rasmussen
2012-08-19 10:12 ` Juri Lelli
2012-08-17 8:43 ` Paul Turner
2012-08-20 15:55 ` Vincent Guittot
2012-08-20 15:36 ` Vincent Guittot
2012-08-21 0:58 ` Alex Shi
2012-08-21 11:05 ` Vincent Guittot
2012-08-15 14:24 ` Rakib Mullick
2012-08-15 14:55 ` Peter Zijlstra
2012-08-15 22:58 ` Rakib Mullick
2012-08-16 5:26 ` Alex Shi
2012-08-16 4:57 ` Alex Shi
2012-08-16 8:05 ` Rakib Mullick
2012-08-15 16:19 ` Matthew Garrett
2012-08-16 5:03 ` Alex Shi
2012-08-16 5:31 ` Matthew Garrett
2012-08-16 5:39 ` Alex Shi
2012-08-16 5:45 ` Matthew Garrett
2012-08-16 13:57 ` Arjan van de Ven
2012-08-20 15:47 ` Christoph Lameter
2012-08-20 15:52 ` Matthew Garrett
2012-08-20 19:22 ` Christoph Lameter
2012-08-20 15:47 ` Vincent Guittot
2012-08-21 1:05 ` Alex Shi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120821161324.GA29665@srcf.ucam.org \
--to=mjg59@srcf.ucam.org \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=alex.shi@intel.com \
--cc=arjan@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=pjt@google.com \
--cc=suresh.b.siddha@intel.com \
--cc=svaidy@linux.vnet.ibm.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=vincent.guittot@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).