linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vincent Guittot <vincent.guittot@linaro.org>
To: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
	dietmar.eggemann@arm.com, rostedt@goodmis.org,
	bsegall@google.com, mgorman@suse.de,
	linux-kernel@vger.kernel.org
Cc: valentin.schneider@arm.com, pauld@redhat.com, hdanton@sina.com,
	Vincent Guittot <vincent.guittot@linaro.org>
Subject: [PATCH 0/4 v2] sched/fair: Improve fairness between cfs tasks
Date: Mon, 21 Sep 2020 09:24:20 +0200	[thread overview]
Message-ID: <20200921072424.14813-1-vincent.guittot@linaro.org> (raw)

When the system doesn't have enough cycles for all tasks, the scheduler
must ensure a fair split of those CPUs cycles between CFS tasks. The
fairness of some use cases can't be solved with a static distribution of
the tasks on the system and requires a periodic rebalancing of the system
but this dynamic behavior is not always optimal and the fair distribution
of the CPU's time is not always ensured.

The patchset improves the fairness by decreasing  the constraint for
selecting migratable tasks with the number of failed load balance. This
change enables then to decrease the imbalance threshold because 1st LB
will try to migrate tasks that fully match the imbalance.

Some tests results:

- small 2 x 4 cores arm64 system

hackbench -l (256000/#grp) -g #grp

grp    tip/sched/core         +patchset             improvement
1      1.420(+/- 11.72 %)     1.382(+/-10.50 %)     2.72 %
4      1.295(+/-  2.72 %)     1.218(+/- 2.97 %)     0.76 %
8      1.220(+/-  2.17 %)     1.218(+/- 1.60 %)     0.17 %
16     1.258(+/-  1.88 %)     1.250(+/- 1,78 %)     0.58 %


fairness tests: run always running rt-app threads
monitor the ratio between min/max work done by threads

                  v5.9-rc1             w/ patchset
9 threads  avg     78.3% (+/- 6.60%)   91.20% (+/- 2.44%)
           worst   68.6%               85.67%

11 threads avg     65.91% (+/- 8.26%)  91.34% (+/- 1.87%)
           worst   53.52%              87.26%

- large 2 nodes x 28 cores x 4 threads arm64 system

The hackbench tests that I usually run as well as the sp.C.x and lu.C.x
tests with 224 threads have not shown any difference with a mix of less
than 0.5% of improvements or regressions.

Changes for v2:
- rebased on tip/sched/core
- added comment for patch 3
- added acked and reviewed tags

Vincent Guittot (4):
  sched/fair: relax constraint on task's load during load balance
  sched/fair: reduce minimal imbalance threshold
  sched/fair: minimize concurrent LBs between domain level
  sched/fair: reduce busy load balance interval

 kernel/sched/fair.c     | 13 +++++++++++--
 kernel/sched/topology.c |  4 ++--
 2 files changed, 13 insertions(+), 4 deletions(-)

-- 
2.17.1


             reply	other threads:[~2020-09-21  7:24 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-21  7:24 Vincent Guittot [this message]
2020-09-21  7:24 ` [PATCH 1/4 v2] sched/fair: relax constraint on task's load during load balance Vincent Guittot
2020-09-23 14:43   ` Valentin Schneider
2020-09-29  7:56   ` [tip: sched/core] sched/fair: Relax " tip-bot2 for Vincent Guittot
2020-09-21  7:24 ` [PATCH 2/4 v2] sched/fair: reduce minimal imbalance threshold Vincent Guittot
2020-09-23 14:43   ` Valentin Schneider
2020-09-29  7:56   ` [tip: sched/core] sched/fair: Reduce " tip-bot2 for Vincent Guittot
2020-09-21  7:24 ` [PATCH 3/4 v2] sched/fair: minimize concurrent LBs between domain level Vincent Guittot
2020-09-23 14:43   ` Valentin Schneider
2020-09-29  7:56   ` [tip: sched/core] sched/fair: Minimize " tip-bot2 for Vincent Guittot
2020-09-21  7:24 ` [PATCH 4/4 v2] sched/fair: reduce busy load balance interval Vincent Guittot
2020-09-23 14:43   ` Valentin Schneider
2020-09-29  7:56   ` [tip: sched/core] sched/fair: Reduce " tip-bot2 for Vincent Guittot
2020-09-23 15:47 ` [PATCH 0/4 v2] sched/fair: Improve fairness between cfs tasks Mel Gorman

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=20200921072424.14813-1-vincent.guittot@linaro.org \
    --to=vincent.guittot@linaro.org \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=hdanton@sina.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=pauld@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=valentin.schneider@arm.com \
    /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;
as well as URLs for NNTP newsgroup(s).