From: Valentin Schneider <valentin.schneider@arm.com>
To: Vincent Guittot <vincent.guittot@linaro.org>,
peterz@infradead.org, mingo@kernel.org,
linux-kernel@vger.kernel.org
Cc: Morten.Rasmussen@arm.com
Subject: Re: [PATCH v2 3/3] sched/fair: fix unnecessary increase of balance interval
Date: Mon, 17 Dec 2018 16:56:18 +0000 [thread overview]
Message-ID: <f6443ca2-3e82-d4eb-deb8-2aff44c618e2@arm.com> (raw)
In-Reply-To: <1544803317-7610-4-git-send-email-vincent.guittot@linaro.org>
Hi Vincent,
About time I had a look at this one...
On 14/12/2018 16:01, Vincent Guittot wrote:
> In case of active balance, we increase the balance interval to cover
> pinned tasks cases not covered by all_pinned logic.
AFAIUI the balance increase is there to have plenty of time to
stop the task before going through another load_balance().
Seeing as there is a cpus_allowed check that leads to
env.flags |= LBF_ALL_PINNED;
goto out_one_pinned;
in the active balancing part of load_balance(), the condition you're
changing should never be hit when we have pinned tasks. So you may want
to rephrase that bit.
> Neverthless, the active
> migration triggered by asym packing should be treated as the normal
> unbalanced case and reset the interval to default value otherwise active
> migration for asym_packing can be easily delayed for hundreds of ms
> because of this all_pinned detection mecanism.
Mmm so it's not exactly clear why we need this change. If we double the
interval because of a pinned task we wanted to active balance, well it's
just regular pinned task issues and we can't do much about it.
The only scenario I can think of is if you had a workload where you wanted
to do an active balance in several successive load_balance(), in which case
you would keep increasing the interval even though you do migrate a task
every time (which would harm every subsequent active_balance).
In that case every active_balance "user" (pressured CPU, misfit) is
affected, so maybe what we want is something like this:
-----8<-----
@@ -9136,13 +9149,11 @@ static int load_balance(int this_cpu, struct rq *this_rq,
sd->balance_interval = sd->min_interval;
} else {
/*
- * If we've begun active balancing, start to back off. This
- * case may not be covered by the all_pinned logic if there
- * is only 1 task on the busy runqueue (because we don't call
- * detach_tasks).
+ * If we've begun active balancing, start to back off.
+ * Don't increase too much in case we have more active balances
+ * coming up.
*/
- if (sd->balance_interval < sd->max_interval)
- sd->balance_interval *= 2;
+ sd->balance_interval = 2 * sd->min_interval;
}
goto out;
----->8-----
Maybe we want a larger threshold - truth be told, it all depends on how
long the cpu stopper can take and if that delay increase is still relevant
nowadays.
>
> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
> ---
> kernel/sched/fair.c | 27 +++++++++++++++------------
> 1 file changed, 15 insertions(+), 12 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 9591e7a..487287e 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -8857,21 +8857,24 @@ static struct rq *find_busiest_queue(struct lb_env *env,
> */
> #define MAX_PINNED_INTERVAL 512
>
> +static inline bool
> +asym_active_balance(struct lb_env *env)
> +{
> + /*
> + * ASYM_PACKING needs to force migrate tasks from busy but
> + * lower priority CPUs in order to pack all tasks in the
> + * highest priority CPUs.
> + */
> + return env->idle != CPU_NOT_IDLE && (env->sd->flags & SD_ASYM_PACKING) &&
> + sched_asym_prefer(env->dst_cpu, env->src_cpu);
> +}
> +
> static int need_active_balance(struct lb_env *env)
> {
> struct sched_domain *sd = env->sd;
>
> - if (env->idle != CPU_NOT_IDLE) {
> -
> - /*
> - * ASYM_PACKING needs to force migrate tasks from busy but
> - * lower priority CPUs in order to pack all tasks in the
> - * highest priority CPUs.
> - */
> - if ((sd->flags & SD_ASYM_PACKING) &&
> - sched_asym_prefer(env->dst_cpu, env->src_cpu))
> - return 1;
> - }
> + if (asym_active_balance(env))
> + return 1;
>
> /*
> * The dst_cpu is idle and the src_cpu CPU has only 1 CFS task.
> @@ -9150,7 +9153,7 @@ static int load_balance(int this_cpu, struct rq *this_rq,
> } else
> sd->nr_balance_failed = 0;
>
> - if (likely(!active_balance)) {
> + if (likely(!active_balance) || asym_active_balance(&env)) {
AFAICT this makes us reset the interval whenever we do an asym packing
active balance (if the task is pinned we would goto out_one_pinned).
This goes against the logic I had understood so far and that I explained
higher up.
> /* We were unbalanced, so reset the balancing interval */
> sd->balance_interval = sd->min_interval;
> } else {
>
next prev parent reply other threads:[~2018-12-17 16:56 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-14 16:01 [PATCH v2 0/3] sched/fair: some fixes for asym_packing Vincent Guittot
2018-12-14 16:01 ` [PATCH v2 1/3] sched/fair: fix rounding issue for asym packing Vincent Guittot
2018-12-18 17:32 ` Valentin Schneider
2018-12-19 8:32 ` Vincent Guittot
2018-12-19 11:58 ` Valentin Schneider
2018-12-19 13:39 ` Vincent Guittot
2018-12-19 14:59 ` Valentin Schneider
2018-12-19 15:05 ` Vincent Guittot
2018-12-19 15:11 ` Valentin Schneider
2018-12-19 15:20 ` Vincent Guittot
2018-12-19 15:30 ` Valentin Schneider
2018-12-19 15:54 ` Vincent Guittot
2018-12-14 16:01 ` [PATCH v2 2/3] sched/fair: trigger asym_packing during idle load balance Vincent Guittot
2018-12-17 16:59 ` Valentin Schneider
2018-12-18 8:17 ` Vincent Guittot
2018-12-18 12:00 ` Valentin Schneider
2018-12-14 16:01 ` [PATCH v2 3/3] sched/fair: fix unnecessary increase of balance interval Vincent Guittot
2018-12-17 16:56 ` Valentin Schneider [this message]
2018-12-18 9:32 ` Vincent Guittot
2018-12-18 11:46 ` Valentin Schneider
2018-12-18 13:23 ` Vincent Guittot
2018-12-18 14:09 ` Valentin Schneider
2018-12-19 8:27 ` Vincent Guittot
2018-12-19 11:16 ` Valentin Schneider
2018-12-19 13:29 ` Vincent Guittot
2018-12-19 15:54 ` Valentin Schneider
2018-12-19 16:54 ` 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=f6443ca2-3e82-d4eb-deb8-2aff44c618e2@arm.com \
--to=valentin.schneider@arm.com \
--cc=Morten.Rasmussen@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome