From: Peter Zijlstra <peterz@infradead.org>
To: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: linux-kernel@vger.kernel.org,
Morten Rasmussen <morten.rasmussen@arm.com>
Subject: Re: [PATCH 3/7] sched/fair: Correct unit of load_above_capacity
Date: Tue, 3 May 2016 12:52:33 +0200 [thread overview]
Message-ID: <20160503105233.GN3430@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <1461958364-675-4-git-send-email-dietmar.eggemann@arm.com>
On Fri, Apr 29, 2016 at 08:32:40PM +0100, Dietmar Eggemann wrote:
> From: Morten Rasmussen <morten.rasmussen@arm.com>
>
> In calculate_imbalance() load_above_capacity currently has the unit
> [load] while it is used as being [load/capacity]. Not only is it wrong it
> also makes it unlikely that load_above_capacity is ever used as the
> subsequent code picks the smaller of load_above_capacity and the avg_load
> difference between the local and the busiest sched_groups.
>
> This patch ensures that load_above_capacity has the right unit
> [load/capacity].
>
> Signed-off-by: Morten Rasmussen <morten.rasmussen@arm.com>
> ---
> kernel/sched/fair.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index bc19fee94f39..c066574cff04 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -7016,9 +7016,11 @@ static inline void calculate_imbalance(struct lb_env *env, struct sd_lb_stats *s
> local->group_type == group_overloaded) {
> load_above_capacity = busiest->sum_nr_running *
> SCHED_LOAD_SCALE;
Given smpnice and cgroups; this starting point seems somewhat random.
Then again, without cgroup and assuming all tasks are nice-0 it is still
true. But I think the cgroup muck is rather universal these days.
The above SCHED_LOAD_SCALE is the 1 -> load metric, right?
> - if (load_above_capacity > busiest->group_capacity)
> + if (load_above_capacity > busiest->group_capacity) {
> load_above_capacity -= busiest->group_capacity;
> - else
> + load_above_capacity *= SCHED_LOAD_SCALE;
> + load_above_capacity /= busiest->group_capacity;
And this one does load->capacity
> + } else
> load_above_capacity = ~0UL;
> }
Is there anything better we can do? I know there's a fair bit of cruft
in; but these assumptions that SCHED_LOAD_SCALE is one task, just bug
the hell out of me.
Would it make sense to make load_balance()->detach_tasks() ensure
busiest->sum_nr_running >= busiest->group_weight or so?
next prev parent reply other threads:[~2016-05-03 10:52 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-29 19:32 [PATCH 0/7] sched/fair: fixes and cleanups Dietmar Eggemann
2016-04-29 19:32 ` [PATCH 1/7] sched/fair: Remove remaining power aware scheduling comments Dietmar Eggemann
2016-05-05 9:42 ` [tip:sched/core] sched/fair: Remove stale " tip-bot for Dietmar Eggemann
2016-04-29 19:32 ` [PATCH 2/7] sched/fair: Fix comment in calculate_imbalance() Dietmar Eggemann
2016-05-05 9:42 ` [tip:sched/core] " tip-bot for Dietmar Eggemann
2016-04-29 19:32 ` [PATCH 3/7] sched/fair: Correct unit of load_above_capacity Dietmar Eggemann
2016-05-03 10:52 ` Peter Zijlstra [this message]
2016-05-03 14:56 ` Morten Rasmussen
2016-05-12 10:31 ` [tip:sched/core] " tip-bot for Morten Rasmussen
2016-05-12 21:48 ` Yuyang Du
2016-05-13 8:22 ` Vincent Guittot
2016-05-19 15:36 ` Morten Rasmussen
2016-05-20 8:17 ` Vincent Guittot
2016-05-23 20:24 ` Yuyang Du
2016-05-30 22:35 ` Yuyang Du
2016-04-29 19:32 ` [PATCH 4/7] sched/fair: Clean up the logic in fix_small_imbalance() Dietmar Eggemann
2016-05-03 10:12 ` Peter Zijlstra
2016-05-03 16:53 ` Dietmar Eggemann
2016-04-29 19:32 ` [PATCH 5/7] sched/fair: Remove cpu_avg_load_per_task() Dietmar Eggemann
2016-04-29 19:32 ` [PATCH 6/7] sched/fair: Reorder code in update_sd_lb_stats() Dietmar Eggemann
2016-04-29 19:32 ` [PATCH 7/7] sched/fair: Use group_cfs_rq(se) instead of se->my_q Dietmar Eggemann
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=20160503105233.GN3430@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=dietmar.eggemann@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=morten.rasmussen@arm.com \
/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.