[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150815091523.GB10304@worktop.programming.kicks-ass.net>
Date: Sat, 15 Aug 2015 11:15:23 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Morten Rasmussen <morten.rasmussen@....com>
Cc: mingo@...hat.com, vincent.guittot@...aro.org,
daniel.lezcano@...aro.org,
Dietmar Eggemann <Dietmar.Eggemann@....com>,
yuyang.du@...el.com, mturquette@...libre.com, rjw@...ysocki.net,
Juri Lelli <Juri.Lelli@....com>, sgurrappadi@...dia.com,
pang.xunlei@....com.cn, linux-kernel@...r.kernel.org,
linux-pm@...r.kernel.org
Subject: Re: [RFCv5 PATCH 34/46] sched: Enable idle balance to pull single
task towards cpu with higher capacity
On Tue, Jul 07, 2015 at 07:24:17PM +0100, Morten Rasmussen wrote:
> +++ b/kernel/sched/fair.c
> @@ -7569,6 +7569,13 @@ static int need_active_balance(struct lb_env *env)
> return 1;
> }
>
> + if ((capacity_of(env->src_cpu) < capacity_of(env->dst_cpu)) &&
> + env->src_rq->cfs.h_nr_running == 1 &&
> + cpu_overutilized(env->src_cpu) &&
> + !cpu_overutilized(env->dst_cpu)) {
> + return 1;
> + }
> +
> return unlikely(sd->nr_balance_failed > sd->cache_nice_tries+2);
> }
Doesn't this allow for a nice game of ping-pong? Where if a task runs on
CPU X and generates interrupts there, its capacity will lower and we'll
migrate it over to CPU Y because that isn't receiving interrupts.
Now the task is running on Y, will generate interrupts there, and sees X
as a more attractive destination.
goto 1
--
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