From: Valentin Schneider <valentin.schneider@arm.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/4] sched/fair: reduce minimal imbalance threshold
Date: Wed, 16 Sep 2020 09:33:48 +0100 [thread overview]
Message-ID: <jhjd02m5deb.mognet@arm.com> (raw)
In-Reply-To: <CAKfTPtC0Sf6SN+rqjQje-kXJiOaLzc0XnXqzS3hOF2FE=FscMA@mail.gmail.com>
On 16/09/20 07:53, Vincent Guittot wrote:
> On Tue, 15 Sep 2020 at 21:04, Valentin Schneider
> <valentin.schneider@arm.com> wrote:
>> AIUI this is the culprit:
>>
>> if (100 * busiest->avg_load <=
>> env->sd->imbalance_pct * local->avg_load)
>> goto out_balanced;
>>
>> As in your case imbalance_pct=120 becomes the tipping point.
>>
>> Now, ultimately this would need to scale based on the underlying topology,
>> right? If you have a system with 2x32 cores running {33 threads, 34
>> threads}, the tipping point becomes imbalance_pct≈103; but then since you
>> have this many more cores, it is somewhat questionable.
>
> I wanted to stay conservative and to not trigger too much task
> migration because of small imbalance so I decided to decrease the
> default threshold to the same level as the MC groups but this can
> still generate unfairness. With your example of 2x32 cores, if you end
> up with 33 tasks in one group and 38 in the other one, the system is
> overloaded so you use load and imbalance_pct but the imbalance will
> stay below the new threshold and the 33 tasks will have 13% more
> running time.
>
> This new imbalance_pct seems a reasonable step to decrease the unfairness
>
No major complaint on the change itself, it's just that this static
imbalance_pct assignment is something I've never really been satisfied with
- at the same time figuring a (or several) correct value from the topology
isn't straightforward either.
At the same time, I believe Peter would be happy to get rid of the decimal
faff and make it all simple shifts, which would limit how much we can
fine-tune these (not necessarily a bad thing).
next prev parent reply other threads:[~2020-09-16 8:33 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-14 10:03 [PATCH 0/4] sched/fair: Improve fairness between cfs tasks Vincent Guittot
2020-09-14 10:03 ` [PATCH 1/4] sched/fair: relax constraint on task's load during load balance Vincent Guittot
2020-09-14 10:03 ` [PATCH 2/4] sched/fair: reduce minimal imbalance threshold Vincent Guittot
2020-09-15 19:04 ` Valentin Schneider
2020-09-16 6:53 ` Vincent Guittot
2020-09-16 8:33 ` Valentin Schneider [this message]
2020-09-14 10:03 ` [PATCH 3/4] sched/fair: minimize concurrent LBs between domain level Vincent Guittot
2020-09-15 19:04 ` Valentin Schneider
2020-09-16 6:54 ` Vincent Guittot
2020-09-14 10:03 ` [PATCH 4/4] sched/fair: reduce busy load balance interval Vincent Guittot
2020-09-15 9:11 ` Jiang Biao
2020-09-15 9:28 ` Vincent Guittot
2020-09-15 11:36 ` Jiang Biao
2020-09-15 12:42 ` Vincent Guittot
2020-09-16 1:14 ` Jiang Biao
2020-09-15 19:04 ` Valentin Schneider
2020-09-16 7:02 ` Vincent Guittot
2020-09-16 8:34 ` Valentin Schneider
2020-09-14 11:42 ` [PATCH 0/4] sched/fair: Improve fairness between cfs tasks peterz
2020-09-14 12:53 ` Phil Auld
2020-09-14 16:03 ` Vincent Guittot
2020-09-14 15:50 ` Mel Gorman
2020-09-14 16:04 ` Vincent Guittot
2020-09-18 16:39 ` Phil Auld
2020-09-18 17:27 ` Phil Auld
2020-09-15 19:05 ` Valentin Schneider
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=jhjd02m5deb.mognet@arm.com \
--to=valentin.schneider@arm.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome