From: Arjan van de Ven <arjan@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Morten Rasmussen <morten.rasmussen@arm.com>,
mingo@kernel.org, vincent.guittot@linaro.org,
preeti@linux.vnet.ibm.com, alex.shi@intel.com, efault@gmx.de,
pjt@google.com, len.brown@intel.com, corbet@lwn.net,
akpm@linux-foundation.org, torvalds@linux-foundation.org,
tglx@linutronix.de, catalin.marinas@arm.com,
linux-kernel@vger.kernel.org, linaro-kernel@lists.linaro.org
Subject: Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal
Date: Mon, 15 Jul 2013 15:52:32 -0700 [thread overview]
Message-ID: <51E47D30.5030203@linux.intel.com> (raw)
In-Reply-To: <20130715211230.GG23818@dyad.programming.kicks-ass.net>
On 7/15/2013 2:12 PM, Peter Zijlstra wrote:
> On Mon, Jul 15, 2013 at 11:06:50PM +0200, Peter Zijlstra wrote:
>> OK, but isn't that part of why the micro controller might not make you go
>> faster even if you do program a higher P state?
>>
>> But yes, I understand this issue in the 'traditional' cpufreq sense. There's no
>> point in ramping the speed if all you do is stall more.
>>
>> But I was under the impression the 'hardware' was doing this. If not then we
>> need the whole go-faster and go-slower thing and places to call them and means
>> to determine to call them etc.
>
>
> So with the scheduler measuring cpu utilization we could say to go-faster when
> u>0.8 and go-slower when u<0.75 or so. Lacking any better metrics like the
> stall stuff etc.
>
> So I understand that ondemand spends quite a lot of time 'sampling' what the
> system does while the scheduler mostly already knows this.
yeah ondemand does this, but ondemand is actually a pretty bad governor.
not because of the sampling, but because of its algorithm.
if you look at what the ondemand algorithm tries to do, it's trying to
manage the cpu "frequency" primarily for when the system is idle.
Ten to twelve years ago, this was actually important and it does a decent
job on that.
HOWEVER, on modern CPUs, even many of the ARM ones, the frequency
when you're idle is zero anyway regardless of what you as OS ask for.
And when Linux went tickless, ondemand went to deferred timers, which make it
even worse.
btw technically ondemand does not sample things, you may (or may not) understand
what it does.
Every 10 (or 100) milliseconds, ondemand makes a new P state decision.
It does this by asking the scheduler the time used, does a delta and
ends up at a utilization %age which then goes into a formula.
It's not that ondemand samples inbetween decision moments to see if the system
is busy or not; the microaccounting that the scheduler does is used instead,
and only at decision moments.
next prev parent reply other threads:[~2013-07-15 22:52 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-09 15:55 [RFC][PATCH 0/9] sched: Power scheduler design proposal Morten Rasmussen
2013-07-09 15:55 ` [RFC][PATCH 1/9] sched: Introduce power scheduler Morten Rasmussen
2013-07-09 16:48 ` Arjan van de Ven
2013-07-10 2:10 ` Arjan van de Ven
2013-07-10 11:11 ` Morten Rasmussen
2013-07-10 11:19 ` Vincent Guittot
2013-07-09 15:55 ` [RFC][PATCH 2/9] sched: Redirect update_cpu_power to sched/power.c Morten Rasmussen
2013-07-09 15:55 ` [RFC][PATCH 3/9] sched: Make select_idle_sibling() skip cpu with a cpu_power of 1 Morten Rasmussen
2013-07-09 15:55 ` [RFC][PATCH 4/9] sched: Make periodic load-balance disregard cpus " Morten Rasmussen
2013-07-09 15:55 ` [RFC][PATCH 5/9] sched: Make idle_balance() skip " Morten Rasmussen
2013-07-09 15:55 ` [RFC][PATCH 6/9] sched: power: add power_domain data structure Morten Rasmussen
2013-07-09 15:55 ` [RFC][PATCH 7/9] sched: power: Add power driver interface Morten Rasmussen
2013-07-09 15:55 ` [RFC][PATCH 8/9] sched: power: Add initial frequency scaling support to power scheduler Morten Rasmussen
2013-07-10 13:10 ` Arjan van de Ven
2013-07-12 12:51 ` Morten Rasmussen
2013-07-12 13:06 ` Catalin Marinas
2013-07-12 15:37 ` Arjan van de Ven
2013-07-09 15:55 ` [RFC][PATCH 9/9] sched: power: cpufreq: Initial schedpower cpufreq governor Morten Rasmussen
2013-07-09 16:58 ` [RFC][PATCH 0/9] sched: Power scheduler design proposal Arjan van de Ven
2013-07-10 11:16 ` Morten Rasmussen
2013-07-10 13:05 ` Arjan van de Ven
2013-07-12 12:46 ` Morten Rasmussen
2013-07-12 15:35 ` Arjan van de Ven
2013-07-12 13:00 ` Catalin Marinas
2013-07-12 15:44 ` Arjan van de Ven
2013-07-11 11:34 ` Preeti U Murthy
2013-07-12 13:48 ` Morten Rasmussen
2013-07-15 3:43 ` Preeti U Murthy
2013-07-15 9:55 ` Catalin Marinas
2013-07-15 15:24 ` Arjan van de Ven
2013-07-12 13:31 ` Catalin Marinas
2013-07-13 6:49 ` Peter Zijlstra
2013-07-13 10:23 ` Catalin Marinas
2013-07-15 7:53 ` Vincent Guittot
2013-07-15 20:39 ` Peter Zijlstra
2013-07-16 12:42 ` Catalin Marinas
2013-07-16 15:23 ` Arjan van de Ven
2013-07-17 14:14 ` Catalin Marinas
2013-07-24 13:50 ` Morten Rasmussen
2013-07-24 15:16 ` Arjan van de Ven
2013-07-24 16:46 ` Morten Rasmussen
2013-07-24 16:48 ` Arjan van de Ven
2013-07-25 8:00 ` Morten Rasmussen
2013-07-13 14:40 ` Arjan van de Ven
2013-07-15 19:59 ` Peter Zijlstra
2013-07-15 20:37 ` Arjan van de Ven
2013-07-15 21:03 ` Peter Zijlstra
2013-07-15 22:46 ` Arjan van de Ven
2013-07-16 20:45 ` David Lang
2013-07-15 20:41 ` Arjan van de Ven
2013-07-15 21:06 ` Peter Zijlstra
2013-07-15 21:12 ` Peter Zijlstra
2013-07-15 22:52 ` Arjan van de Ven [this message]
2013-07-16 17:38 ` Peter Zijlstra
2013-07-16 18:44 ` Arjan van de Ven
2013-07-16 19:21 ` Peter Zijlstra
2013-07-16 19:57 ` Arjan van de Ven
2013-07-16 20:17 ` Peter Zijlstra
2013-07-16 20:21 ` Arjan van de Ven
2013-07-16 20:32 ` Arjan van de Ven
2013-07-15 22:46 ` Arjan van de Ven
2013-07-13 16:14 ` Arjan van de Ven
2013-07-15 2:05 ` Alex Shi
2013-07-24 13:16 ` Morten Rasmussen
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=51E47D30.5030203@linux.intel.com \
--to=arjan@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=alex.shi@intel.com \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=efault@gmx.de \
--cc=len.brown@intel.com \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=morten.rasmussen@arm.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=preeti@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).