All of lore.kernel.org
 help / color / mirror / Atom feed
From: morten.rasmussen@arm.com (Morten Rasmussen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] arm64: topology: Tell the scheduler about the relative power of cores
Date: Thu, 12 Dec 2013 13:36:43 +0000	[thread overview]
Message-ID: <20131212133643.GE28621@e103034-lin> (raw)
In-Reply-To: <20131212120649.GB5367@sirena.org.uk>

On Thu, Dec 12, 2013 at 12:06:49PM +0000, Mark Brown wrote:
> On Thu, Dec 12, 2013 at 11:35:12AM +0000, Morten Rasmussen wrote:
> 
> > I know that this is how it is currently done for ARMv7 and one could
> > argue that we should do the same for ARMv8 until we have a better
> > solution. I just want to highlight that setting cpu_power this way is
> > not generally the right thing to do for big.LITTLE. It will have to be
> > fixed eventually.
> 
> Right, there's a good solid reason for all the work on the scheduler.  I
> definitely think we ought to be following the same approach on both
> ARMv7 and ARMv8 to avoid confusion between people based on the platform
> they're working on.

That is fair enough.

> 
> If you're saying that the current ARMv7 code is always worse than doing
> nothing then clearly we ought to be removing that code from ARMv7 rather
> than hurting performance.  I'd been under the impression that what we
> had there was not ideal but better than nothing in mainline rather than
> actively harmful.

For some scenarios it might be better to set cpu_power to reflect the
relative performance, for others it is worse due to the way cpu_power
is currently used in the scheduler.

Setting cpu_power as it is done for v7 may bias the scheduler to put
heavier tasks on big cpus and will generally put more task on big cpus,
which is a good thing for some scenarios. However, if you have parallel
workloads that spawn a worker thread for each cpu and does dynamic work
distribution in user-space (OpenMP applications for example), then
setting cpu_power will put two worker threads on some big cpus and leave
some little cpus idle resulting in slower completion time. It happens on
TC2.

We need the code (or something very similar) later when the scheduler
has been fixed. For v7 it has been left in waiting for that fix, it
doesn't harm when using the reference big.LITTLE patches. We can do the
same for v8 to avoid confusion.

Morten

  reply	other threads:[~2013-12-12 13:36 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-11 20:00 [PATCH 1/3] arm64: topology: Implement basic CPU topology support Mark Brown
2013-12-11 20:00 ` [PATCH 2/3] arm64: topology: Tell the scheduler about the relative power of cores Mark Brown
2013-12-12 11:35   ` Morten Rasmussen
2013-12-12 12:06     ` Mark Brown
2013-12-12 13:36       ` Morten Rasmussen [this message]
2013-12-12 17:39         ` Catalin Marinas
2013-12-12 18:06           ` Mark Brown
2013-12-11 20:00 ` [PATCH 3/3] arm64: topology: Add support for topology DT bindings Mark Brown
2013-12-12  7:13 ` [PATCH 1/3] arm64: topology: Implement basic CPU topology support Hanjun Guo
2013-12-12 10:22   ` Mark Brown
2014-03-05  8:59 [PATCH 1/3] arm64: topology: Add support for topology DT bindings Mark Brown
2014-03-05  8:59 ` [PATCH 2/3] arm64: topology: Tell the scheduler about the relative power of cores Mark Brown
2014-03-19 18:02 [PATCH 1/3] arm64: topology: Add support for topology DT bindings Mark Brown
2014-03-19 18:02 ` [PATCH 2/3] arm64: topology: Tell the scheduler about the relative power of cores Mark Brown

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=20131212133643.GE28621@e103034-lin \
    --to=morten.rasmussen@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.