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 3/3] sched/fair: fix unnecessary increase of balance interval
Date: Thu, 20 Dec 2018 11:22:45 +0000 [thread overview]
Message-ID: <c482361e-cfb4-d172-32c3-4d82ceb1e7d2@arm.com> (raw)
In-Reply-To: <1545292547-18770-4-git-send-email-vincent.guittot@linaro.org>
On 20/12/2018 07:55, Vincent Guittot wrote:
> In case of active balance, we increase the balance interval to cover
> pinned tasks cases not covered by all_pinned logic. 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 pinned task detection mecanism.
> The same happen to other conditions tested in need_active_balance() like
> mistfit task and when the capacity of src_cpu is reduced compared to
> dst_cpu (see comments in need_active_balance() for details).
>
> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
> ---
> kernel/sched/fair.c | 40 +++++++++++++++++++++++++++-------------
> 1 file changed, 27 insertions(+), 13 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 487c73e..9b1e701 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -8849,21 +8849,25 @@ static struct rq *find_busiest_queue(struct lb_env *env,
> */
> #define MAX_PINNED_INTERVAL 512
>
> -static int need_active_balance(struct lb_env *env)
> +static inline bool
> +asym_active_balance(struct lb_env *env)
> {
> - struct sched_domain *sd = env->sd;
> + /*
> + * 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);
> +}
>
> - if (env->idle != CPU_NOT_IDLE) {
> +static inline bool
> +voluntary_active_balance(struct lb_env *env)
> +{
> + struct sched_domain *sd = env->sd;
>
> - /*
> - * 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.
> @@ -8881,6 +8885,16 @@ static int need_active_balance(struct lb_env *env)
> if (env->src_grp_type == group_misfit_task)
> return 1;
>
> + return 0;
> +}
> +
Yeah so that's the active balance classification I was afraid of, and I
don't agree with it.
The way I see things, we happen to have some mechanisms that let us know
straight away if we need an active balance (asym packing, misfit, lowered
capacity), and we rely on the sd->nr_balance_failed threshold for the
scenarios where we don't have any more information.
We do happen to have a threshold because we don't want to go overboard with
it, but when it is reached it's a clear sign that we *do* want to active
balance because that's all we can do to try and solve the imbalance.
To me, those are all legitimate reasons to. So they're all "voluntary"
really, we *do* want all of these.
> +static int need_active_balance(struct lb_env *env)
> +{
> + struct sched_domain *sd = env->sd;
> +
> + if (voluntary_active_balance(env))
> + return 1;
> +
> return unlikely(sd->nr_balance_failed > sd->cache_nice_tries+2);
> }
>
> @@ -9142,7 +9156,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) || voluntary_active_balance(&env)) {
So now we reset the interval for all active balances (expect last active
balance case), even when it is done as a last resort because all other
tasks were pinned.
Arguably the current code isn't much better (always increase the interval
when active balancing), but at least it covers this case. It would be a
waste not to take this into account when we can detect this scenario
(I'll reiterate my LBF_ALL_PINNED suggestion).
> /* We were unbalanced, so reset the balancing interval */
> sd->balance_interval = sd->min_interval;
> } else {
>
next prev parent reply other threads:[~2018-12-20 11:22 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-20 7:55 [PATCH v3 0/3] sched/fair: some fixes for asym_packing Vincent Guittot
2018-12-20 7:55 ` [PATCH v3 1/3] sched/fair: fix rounding issue for asym packing Vincent Guittot
2018-12-20 11:16 ` Valentin Schneider
2018-12-20 14:22 ` Vincent Guittot
2018-12-20 14:54 ` [PATCH v4 " Vincent Guittot
2018-12-20 7:55 ` [PATCH 2/3] sched/fair: trigger asym_packing during idle load balance Vincent Guittot
2018-12-20 11:19 ` Valentin Schneider
2018-12-20 14:33 ` Vincent Guittot
2018-12-20 16:12 ` Valentin Schneider
2018-12-20 7:55 ` [PATCH 3/3] sched/fair: fix unnecessary increase of balance interval Vincent Guittot
2018-12-20 11:22 ` Valentin Schneider [this message]
2018-12-20 14:50 ` Vincent Guittot
2018-12-20 17:24 ` Valentin Schneider
2018-12-21 14:49 ` Vincent Guittot
2018-12-21 17:15 ` Valentin Schneider
2018-12-21 17:41 ` Vincent Guittot
-- strict thread matches above, loose matches on Subject: below --
2018-08-07 15:56 [PATCH 0/3] sched/fair: some fixes for asym_packing Vincent Guittot
2018-08-07 15:56 ` [PATCH 3/3] sched/fair: fix unnecessary increase of balance interval Vincent Guittot
2018-12-13 13:52 ` Peter Zijlstra
2018-12-13 15:36 ` 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=c482361e-cfb4-d172-32c3-4d82ceb1e7d2@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
all inboxes | Powered by JetHome®