All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: Vincent Guittot <vincent.guittot@linaro.org>,
	mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
	rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sched/cfs: fix spurious active migration
Date: Mon, 2 Dec 2019 16:12:58 +0100	[thread overview]
Message-ID: <b8cee573-d1a7-bc26-c6d3-4f9e1a4ad330@arm.com> (raw)
In-Reply-To: <1575036287-6052-1-git-send-email-vincent.guittot@linaro.org>

On 29/11/2019 15:04, Vincent Guittot wrote:
> The load balance can fail to find a suitable task during the periodic check
> because  the imbalance is smaller than half of the load of the waiting
> tasks. This results in the increase of the number of failed load balance,
> which can end up to start an active migration. This active migration is
> useless because the current running task is not a better choice than the
> waiting ones. In fact, the current task was probably not running but
> waiting for the CPU during one of the previous attempts and it had already
> not been selected.
> 
> When load balance fails too many times to migrate a task, we should relax
> the contraint on the maximum load of the tasks that can be migrated
> similarly to what is done with cache hotness.
> 
> Before the rework, load balance used to set the imbalance to the average
> load_per_task in order to mitigate such situation. This increased the
> likelihood of migrating a task but also of selecting a larger task than
> needed while more appropriate ones were in the list.

Why not use '&& !env->sd->nr_balance_failed' then? Too aggressive? But
the average load_per_task was calculated at each load balance attempt,
so it would have led to a migration at the first load balance.

This would be in sync with the LB_MIN check in the same switch case
(migrate_load). Although LB_MIN is false by default.

> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
> ---
> 
> I haven't seen any noticable performance changes on the benchmarks that I
> usually run but the problem can be easily highlight with a simple test
> with 9 always running tasks on 8 cores.
> 
>  kernel/sched/fair.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index e0d662a..d1b4fa7 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -7433,7 +7433,14 @@ static int detach_tasks(struct lb_env *env)
>  			    load < 16 && !env->sd->nr_balance_failed)
>  				goto next;
>  
> -			if (load/2 > env->imbalance)
> +			/*
> +			 * Make sure that we don't migrate too much load.
> +			 * Nevertheless, let relax the constraint if
> +			 * scheduler fails to find a good waiting task to
> +			 * migrate.
> +			 */
> +			if (load/2 > env->imbalance &&
> +			    env->sd->nr_balance_failed <= env->sd->cache_nice_tries)
>  				goto next;
>  
>  			env->imbalance -= load;
> 

  parent reply	other threads:[~2019-12-02 15:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-29 14:04 [PATCH] sched/cfs: fix spurious active migration Vincent Guittot
2019-12-02 13:22 ` Peter Zijlstra
2019-12-02 13:51   ` Vincent Guittot
2019-12-02 15:12 ` Dietmar Eggemann [this message]
2019-12-02 15:36   ` Vincent Guittot
2019-12-17 12:39 ` [tip: sched/urgent] " tip-bot2 for Vincent Guittot

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=b8cee573-d1a7-bc26-c6d3-4f9e1a4ad330@arm.com \
    --to=dietmar.eggemann@arm.com \
    --cc=bsegall@google.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --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 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.