lkml.org 
[lkml]   [2014]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] sched: fix spurious active migration
On Tue, Sep 30, 2014 at 10:41:08AM +0200, Vincent Guittot wrote:
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 2a1e6ac..adad532 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -6425,13 +6425,14 @@ static struct sched_group *find_busiest_group(struct lb_env *env)
>
> if (env->idle == CPU_IDLE) {
> /*
> - * This cpu is idle. If the busiest group load doesn't
> - * have more tasks than the number of available cpu's and
> - * there is no imbalance between this and busiest group
> - * wrt to idle cpu's, it is balanced.
> + * This cpu is idle. If the busiest group is not overloaded
> + * and there is no imbalance between this and busiest group
> + * wrt to idle cpus, it is balanced. The imbalance becomes
> + * significant if the diff is greater than 1 otherwise we
> + * might end up to just move the imbalance on another group
> */
> - if ((local->idle_cpus < busiest->idle_cpus) &&
> - busiest->sum_nr_running <= busiest->group_weight)
> + if ((local->idle_cpus <= (busiest->idle_cpus + 1)) &&

So I'm thick and I don't get this one.. In fact I don't seem to
understand the existing code either.

If we're idle, and busiest is overloaded, we want to have tasks. Why
would we care about number of idle cpus etc..

> + !(busiest->group_type == group_overloaded))

Would not: busiest->group_type != group_overloaded, read more natural?
Also, would it make sense to make this the first condition?

> goto out_balanced;
> } else {




\
 
 \ /
  Last update: 2014-09-30 21:21    [W:0.063 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site