From: Morten Rasmussen <morten.rasmussen@arm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: mingo@redhat.com, valentin.schneider@arm.com,
dietmar.eggemann@arm.com, vincent.guittot@linaro.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/7] sched/fair: Avoid unnecessary balancing of asymmetric capacity groups
Date: Tue, 20 Feb 2018 16:22:22 +0000 [thread overview]
Message-ID: <20180220162222.GC4589@e105550-lin.cambridge.arm.com> (raw)
In-Reply-To: <20180219145335.GN25235@hirez.programming.kicks-ass.net>
On Mon, Feb 19, 2018 at 03:53:35PM +0100, Peter Zijlstra wrote:
> On Mon, Feb 19, 2018 at 03:50:12PM +0100, Peter Zijlstra wrote:
> > On Thu, Feb 15, 2018 at 04:20:51PM +0000, Morten Rasmussen wrote:
> > > On systems with asymmetric cpu capacities, a skewed load distribution
> > > might yield better throughput than balancing load per group capacity.
> > > For example, preferring high capacity cpus for compute intensive tasks
> > > leaving low capacity cpus idle rather than balancing the number of idle
> > > cpus across different cpu types. Instead, let load-balance back off if
> > > the busiest group isn't really overloaded.
> >
> > I'm sorry. I just can't seem to make sense of that today. What?
>
> Aah, you're saying that is we have 4+4 bit.little and 4 runnable tasks,
> we would like them running on our big cluster and leave the small
> cluster entirely idle, instead of runnint 2+2.
Yes. Ideally, when are busy, we want to fill up the big cpus first, one
task on each, and if we have more tasks we start using little cpus
before putting additional tasks on any of the bigs. The load per group
capacity metric is sort of working against that up until roughly the
point where we have enough tasks for all the cpus.
> So what about this DynamicQ nonsense? Or is that so unstructured we
> can't really do anything sensible with it?
With DynamiQ we don't have any grouping of the cpu types provided by the
architecture. So we are going end up balancing between individual cpus.
I hope these tweaks should work for DynamiQ too. Always-running tasks on
little cpus should to be flagged as misfits and be picked up by big
cpus. It is still to be verified though.
next prev parent reply other threads:[~2018-02-20 16:22 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-15 16:20 [PATCH 0/7] sched/fair: Migrate 'misfit' tasks on asymmetric capacity systems Morten Rasmussen
2018-02-15 16:20 ` [PATCH 1/7] sched: Add static_key for asymmetric cpu capacity optimizations Morten Rasmussen
2018-02-16 13:47 ` Peter Zijlstra
2018-02-16 15:41 ` Morten Rasmussen
2018-02-16 16:51 ` Peter Zijlstra
2018-02-19 11:49 ` Morten Rasmussen
2018-02-16 17:39 ` Quentin Perret
2018-02-16 17:43 ` Peter Zijlstra
2018-02-15 16:20 ` [PATCH 2/7] sched/fair: Add group_misfit_task load-balance type Morten Rasmussen
2018-02-19 13:56 ` Peter Zijlstra
2018-02-19 13:58 ` Peter Zijlstra
2018-02-20 16:01 ` Morten Rasmussen
2018-02-15 16:20 ` [PATCH 3/7] sched/fair: Consider misfit tasks when load-balancing Morten Rasmussen
2018-02-15 16:20 ` [PATCH 4/7] sched/fair: Avoid unnecessary balancing of asymmetric capacity groups Morten Rasmussen
2018-02-19 14:50 ` Peter Zijlstra
2018-02-19 14:53 ` Peter Zijlstra
2018-02-20 16:22 ` Morten Rasmussen [this message]
2018-02-19 15:10 ` Peter Zijlstra
2018-02-20 16:33 ` Morten Rasmussen
2018-02-20 18:26 ` Peter Zijlstra
2018-02-23 16:38 ` Morten Rasmussen
2018-02-23 16:47 ` Peter Zijlstra
2018-02-26 15:06 ` Morten Rasmussen
2018-02-15 16:20 ` [PATCH 5/7] sched/fair: Kick nohz balance if rq->misfit_task Morten Rasmussen
2018-02-15 16:20 ` [PATCH 6/7] sched: Rename root_domain->overload to should_idle_balance Morten Rasmussen
2018-02-16 9:14 ` Juri Lelli
2018-02-16 9:49 ` Peter Zijlstra
2018-02-16 11:59 ` Valentin Schneider
2018-02-15 16:20 ` [PATCH 7/7] sched/fair: Set sd->should_idle_balance when misfit Morten Rasmussen
2018-02-28 7:46 ` [PATCH 0/7] sched/fair: Migrate 'misfit' tasks on asymmetric capacity systems Gaku Inami
2018-03-01 11:59 ` Valentin Schneider
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=20180220162222.GC4589@e105550-lin.cambridge.arm.com \
--to=morten.rasmussen@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=valentin.schneider@arm.com \
--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