lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140930184129.GM4241@worktop.programming.kicks-ass.net>
Date:	Tue, 30 Sep 2014 20:41:29 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Vincent Guittot <vincent.guittot@...aro.org>
Cc:	mingo@...nel.org, riel@...hat.com, linux-kernel@...r.kernel.org,
	linaro-kernel@...ts.linaro.org
Subject: Re: [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 {


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ