From: Valentin Schneider <valentin.schneider@arm.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Morten Rasmussen <Morten.Rasmussen@arm.com>
Subject: Re: [PATCH 3/3] sched/fair: fix unnecessary increase of balance interval
Date: Thu, 20 Dec 2018 17:24:00 +0000 [thread overview]
Message-ID: <d87cba1f-fa5c-3d82-ec7f-f2c72d40cb30@arm.com> (raw)
In-Reply-To: <CAKfTPtCQTMs=6yGbrfuUGyhwPHWvMODcyyDROVjbURHFxLTxCQ@mail.gmail.com>
On 20/12/2018 14:50, Vincent Guittot wrote:
[...]
>> 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
>
> So i'd like to remind the $subject of this patchset: fix some known
> issues for asym_packing.
> While looking at this, we have added few other voluntary active
> balances because it was "obvious" that this active migration were
> voluntary one. But in fact, we don't have any UC which show a problem
> for those additional UC so far.
>
> The default behavior for active migration is to increase the interval
> Now you want to extend the exception to others active migration UC
> whereas it's not clear that we don't fall in the default active
> migration UC and we should not increase the interval.
Well if we stick to the rule of only increasing balance_interval when
pinned tasks get in the way, it's clear to me that this use case shouldn't
be segregated from the others.
I do agree however that it's not entirely clear if that balance_interval
increase was also intended to slow down the nr_balance_failed migrations.
I had a look at the history and stumbled on:
8102679447da ("[PATCH] sched: improve load balancing pinned tasks")
Which explains the reasoning behind the active_balance balance_interval
increase:
"""
this one attempts to work out whether the balancing failure has
been due to too many tasks pinned on the runqueue. This allows it
to be basically invisible to the regular blancing paths (ie. when
there are no pinned tasks).
"""
So AFAICT that is indeed the rule we should be following, and I would only
increase the balance_interval when there are pinned tasks, not because
of active_balance categories. So here it's a matter of fixing that
condition into what it was meant to be doing.
> What you want is changing the behavior of the scheduler for UC that
> haven't raised any problem where asym_packing has known problem/
>
> Changing default behavior for active migration is not subject of this
> patchset and should be treated in another one like the one discussed
> with peter few days ago
> >> (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 17:24 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
2018-12-20 14:50 ` Vincent Guittot
2018-12-20 17:24 ` Valentin Schneider [this message]
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=d87cba1f-fa5c-3d82-ec7f-f2c72d40cb30@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