From: Morten Rasmussen <morten.rasmussen@arm.com>
To: Arjan van de Ven <arjan@linux.intel.com>
Cc: Catalin Marinas <Catalin.Marinas@arm.com>,
Peter Zijlstra <peterz@infradead.org>,
"mingo@kernel.org" <mingo@kernel.org>,
"vincent.guittot@linaro.org" <vincent.guittot@linaro.org>,
"preeti@linux.vnet.ibm.com" <preeti@linux.vnet.ibm.com>,
"alex.shi@intel.com" <alex.shi@intel.com>,
"efault@gmx.de" <efault@gmx.de>,
"pjt@google.com" <pjt@google.com>,
"len.brown@intel.com" <len.brown@intel.com>,
"corbet@lwn.net" <corbet@lwn.net>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linaro-kernel@lists.linaro.org" <linaro-kernel@lists.linaro.org>
Subject: Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal
Date: Wed, 24 Jul 2013 17:46:07 +0100 [thread overview]
Message-ID: <20130724164607.GF12572@e103034-lin> (raw)
In-Reply-To: <51EFEFD4.4020808@linux.intel.com>
On Wed, Jul 24, 2013 at 04:16:36PM +0100, Arjan van de Ven wrote:
>
> > Given that the power topology is taken into account, a sort
> > left/right-like mechanism would only help performance insensitive tasks
> > on big.LITTLE. Performance sensitive tasks that each can use more than
> > a little cpu should move in the opposite direction. Well, directly to a
> > big cpu, even if some little cpus are idle.
> >
> > It can be discussed whether smaller performance sensitive tasks that
> > would fit on a little cpu should be put on a little or big cpu. That
> > would depend on the nature of the task and if other tasks depend on it.
>
> yeah that makes it fun
>
> just a question for my education; is there overlap between big and little?
> meaning, is the "highest speed of little" as fast, or faster than "lowest speed of big"
> or are those strictly disjoint?
>
> (if there's overlap that gives some room for the scheduler to experiment)
>
It is implementation dependent. And it depends on how you define
performance :-)
That is hardly an answer to your question.
The big and little uarchs are quite different and typically support
different frequencies. For memory bound tasks there is more likely to be
an overlap than for cpu intensive tasks.
I would expect performance to be disjoint for most tasks. If there was
an overlap, the big would probably be less power efficient (as in
energy/instruction) than the little so you would prefer to run on the
little anyway.
In what way would you use the overlap?
next prev parent reply other threads:[~2013-07-24 16:46 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 [this message]
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
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=20130724164607.GF12572@e103034-lin \
--to=morten.rasmussen@arm.com \
--cc=Catalin.Marinas@arm.com \
--cc=akpm@linux-foundation.org \
--cc=alex.shi@intel.com \
--cc=arjan@linux.intel.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=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