From: Rik van Riel <riel@redhat.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Michael Neuling <mikey@neuling.org>,
Ingo Molnar <mingo@kernel.org>, Paul Turner <pjt@google.com>,
jhladky@redhat.com, ktkhai@parallels.com,
tim.c.chen@linux.intel.com,
Nicolas Pitre <nicolas.pitre@linaro.org>
Subject: [PATCH v2] sched: make update_sd_pick_busiest return true on a busier sd
Date: Fri, 25 Jul 2014 15:32:10 -0400 [thread overview]
Message-ID: <20140725153210.47c09bfe@annuminas.surriel.com> (raw)
In-Reply-To: <CAKfTPtBVTgTYmgRKbuhKNZZRuCRK126YVvsG1+a-hjfKao08=g@mail.gmail.com>
Subject: sched: make update_sd_pick_busiest return true on a busier sd
Currently update_sd_pick_busiest only identifies the busiest sd
that is either overloaded, or has a group imbalance. When no
sd is imbalanced or overloaded, the load balancer fails to find
the busiest domain.
This breaks load balancing between domains that are not overloaded,
in the !SD_ASYM_PACKING case. This patch makes update_sd_pick_busiest
return true when the busiest sd yet is encountered.
Behaviour for SD_ASYM_PACKING does not seem to match the comment,
but I have no hardware to test that so I have left the behaviour
of that code unchanged.
It is unclear what to do with the group_imb condition.
Should group_imb override a busier load? If so, should we fix
calculate_imbalance to return a sensible number when the "busiest"
node found has a below average load? We probably need to fix
calculate_imbalance anyway, to deal with an overloaded group that
happens to have a below average load...
Cc: mikey@neuling.org
Cc: peterz@infradead.org
Signed-off-by: Rik van Riel <riel@redhat.com>
---
kernel/sched/fair.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 45943b2..c96044f 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5949,6 +5949,11 @@ static inline void update_sg_lb_stats(struct lb_env *env,
sgs->group_has_free_capacity = 1;
}
+static bool group_overloaded(struct sg_lb_stats *sgs)
+{
+ return sgs->sum_nr_running > sgs->group_capacity_factor;
+}
+
/**
* update_sd_pick_busiest - return 1 on busiest group
* @env: The load balancing environment.
@@ -5957,7 +5962,7 @@ static inline void update_sg_lb_stats(struct lb_env *env,
* @sgs: sched_group statistics
*
* Determine if @sg is a busier group than the previously selected
- * busiest group.
+ * busiest group.
*
* Return: %true if @sg is a busier group than the previously selected
* busiest group. %false otherwise.
@@ -5967,13 +5972,17 @@ static bool update_sd_pick_busiest(struct lb_env *env,
struct sched_group *sg,
struct sg_lb_stats *sgs)
{
+ if (group_overloaded(sgs) && !group_overloaded(&sds->busiest_stat))
+ return true;
+
if (sgs->avg_load <= sds->busiest_stat.avg_load)
return false;
- if (sgs->sum_nr_running > sgs->group_capacity_factor)
+ if (sgs->group_imb)
return true;
- if (sgs->group_imb)
+ /* This is the busiest node. */
+ if (!(env->sd->flags & SD_ASYM_PACKING))
return true;
/*
@@ -5981,8 +5990,7 @@ static bool update_sd_pick_busiest(struct lb_env *env,
* numbered CPUs in the group, therefore mark all groups
* higher than ourself as busy.
*/
- if ((env->sd->flags & SD_ASYM_PACKING) && sgs->sum_nr_running &&
- env->dst_cpu < group_first_cpu(sg)) {
+ if (sgs->sum_nr_running && env->dst_cpu < group_first_cpu(sg)) {
if (!sds->busiest)
return true;
next prev parent reply other threads:[~2014-07-25 19:32 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-22 18:45 [PATCH] " Rik van Riel
2014-07-23 7:41 ` Vincent Guittot
2014-07-25 13:33 ` Rik van Riel
2014-07-25 14:29 ` Vincent Guittot
2014-07-25 14:46 ` Rik van Riel
2014-07-25 14:02 ` Rik van Riel
2014-07-25 14:15 ` Peter Zijlstra
2014-07-25 15:02 ` Vincent Guittot
2014-07-25 15:13 ` Rik van Riel
2014-07-25 15:27 ` Peter Zijlstra
2014-07-25 15:45 ` Rik van Riel
2014-07-25 16:05 ` Peter Zijlstra
2014-07-25 16:22 ` Rik van Riel
2014-07-25 17:57 ` Vincent Guittot
2014-07-25 19:32 ` Rik van Riel [this message]
2014-07-28 8:23 ` [PATCH v2] " Vincent Guittot
2014-07-28 15:04 ` Rik van Riel
2014-07-28 14:30 ` Peter Zijlstra
2014-07-27 23:57 ` [PATCH] " Michael Neuling
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=20140725153210.47c09bfe@annuminas.surriel.com \
--to=riel@redhat.com \
--cc=jhladky@redhat.com \
--cc=ktkhai@parallels.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mikey@neuling.org \
--cc=mingo@kernel.org \
--cc=nicolas.pitre@linaro.org \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=tim.c.chen@linux.intel.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
all inboxes | Powered by JetHome®