linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Ingo Molnar <mingo@kernel.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>,
	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:02:54 +0100	[thread overview]
Message-ID: <20120821170254.0b10ece6@pyramind.ukuu.org.uk> (raw)
In-Reply-To: <20120821151910.GA5359@gmail.com>

> > That's a fundamentally uninteresting thing for the kernel to 
> > know about. [...]
> 
> I disagree.

The kernel has no idea of the power architecture leading up to the plug
socket. The kernel has no idea of the policy concerns of the user.

> > [...] AC/battery is just not an important power management 
> > policy input when compared to various other things.
> 
> Such as?
> 
> The thing is, when I use Linux on a laptop then AC/battery is 
> *the* main policy input.

Along with distance likely to be travelled without a socket being
available, whether you remembered the charger, and a pile of other things
('can I get this built before Linus wakes up').

The kernel isn't capable of computing these other factors. The userspace
can at least make an educated guess,

In the business space its even more complicated because battery/mains may
well only be visible via SNMP queries to the power systems and the bigger
concern may well be heat efficiency. If you are running a cloud your
policy considerations also include things like your current spot
electricity price, outside temperature and your current spot compute price
chargeable.

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

You work for Red Hat, maybe you should ask your distro people if they do.
While you are it at perhaps also some of the ATA power management that
will probably be an order of magnitude more significant could get
included ;)

Seriously. On a typical laptop the things you can do about power are
dominated by the backlight, by disk power (eg idle SATA links), by USB
device power downs where possible, by turning off any unused phys and by
not having the CPU wake up, which means fixing the desktop apps to behave
sensibly.

I'd like to see actual numbers and evidence on a wide range of workloads
the spread/don't spread thing is even measurable given that you've also
got to factor in effects like completing faster and turning everything
off. I'd *really* like to see such evidence on a laptop,which is your
one cited case it might work.

> > Your suggestions aren't a working default mechanism.
> 
> In what way?

For one if the default behaviour is that when I get on the train and am
on battery my video playback begins to stutter due to some kernel
magic then I shall be unamused and file it as a regression.....

Policy is userspace - the desktop can figure out I'm watching movies and
what this means, the kernel can't.

I'd also note there have been repeated attempts to put power management
policy on various OS's by putting the power management policy 

- in the hardware
- in SMM handlers
- in the kernel

and every single one has been a failure because those parts of the system
never have enough information nor do they have enough variety of control
to manage the complexity of input state.

It's a single policy file for a distro to do scheduler configuration
based upon power events. One trivial 'drop it here' shell script. The
difference then being the desktop can be taught to do overrides and
policy properly.

It might be the kernel has important knowledge about what "schedule
for efficiency" means and even to be able to ask the kernel to dot hat
- but it has no idea what the right policy is at any given moment.

ie even if there is a /sys/mumble/schedule_for_efficiency

the echo "1" > and echo "0" > belong in a script

Alan


  parent reply	other threads:[~2012-08-21 15:58 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
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 [this message]
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=20120821170254.0b10ece6@pyramind.ukuu.org.uk \
    --to=alan@lxorguk.ukuu.org.uk \
    --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=mjg59@srcf.ucam.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).