All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brendan Jackman <brendan.jackman@arm.com>
To: Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	linux-kernel@vger.kernel.org
Subject: [PATCH v2 0/2] sched/fair: remote load updates for idle CPUs
Date: Fri,  1 Dec 2017 18:01:55 +0000	[thread overview]
Message-ID: <20171201180157.18937-1-brendan.jackman@arm.com> (raw)

Hi,

Here is the v2, which was just delayed by my holiday.

Until a NOHZ idle balance takes place on behalf of a CPU (which may
never happen), the blocked load of of its root cfs_rq and its
contributions to task group shares are updated only by that CPU. That
means if a CPU goes suddenly from being busy to totally idle, its
load and effect on shares may not be updated for a long time.

Schedutil works around this problem by ignoring the util of CPUs
that were last updated more than a tick ago. However the stale
load does impact task placement: elements that look at load and
util (in particular the slow-path of select_task_rq_fair) can
leave the idle CPUs un-used while other CPUs go unnecessarily
overloaded. Furthermore the stale shares can impact CPU time
allotment.

Two complementary solutions are proposed here:
1. When a task wakes up, if necessary an idle CPU is woken as if to
   perform a NOHZ idle balance, which is then aborted once the load
   of NOHZ idle CPUs has been updated. This solves the problem but
   brings with it extra CPU wakeups, which have an energy cost.
2. During newly-idle load balancing, the load of remote nohz-idle
   CPUs in the sched_domain is updated. When all of the idle CPUs
   were updated in that step, the nohz.next_update field
   is pushed further into the future. This field is used to determine
   the need for triggering the newly-added NOHZ kick. So if such
   newly-idle balances are happening often enough, no additional CPU
   wakeups are required to keep all the CPUs' loads and shares
   contributions updated.

Changes v1 -> v2:

 - Vincent pointed out I broke !CONFIG_NO_HZ_COMMON, fixed that.

 - Tood Kjos pointed out that a stats kick from CPU A can inhibit a
   full balance kick from CPU B. Reduced the scope for that by having
   CPU B convert the pending/ongoing stats kick to a proper balance
   by clearing the NOHZ_STATS_KICK bit in nohz_kick_needed.

Brendan Jackman (1):
  sched/fair: Update blocked load from newly idle balance

Vincent Guittot (1):
  sched: force update of blocked load of idle cpus

 kernel/sched/core.c  |   1 +
 kernel/sched/fair.c  | 128 +++++++++++++++++++++++++++++++++++++++++++++------
 kernel/sched/sched.h |   2 +
 3 files changed, 116 insertions(+), 15 deletions(-)

--
2.14.1

             reply	other threads:[~2017-12-01 18:01 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-01 18:01 Brendan Jackman [this message]
2017-12-01 18:01 ` [PATCH v2 1/2] sched: force update of blocked load of idle cpus Brendan Jackman
2017-12-20 14:03   ` Peter Zijlstra
2017-12-20 14:23     ` Vincent Guittot
2017-12-20 15:01       ` Peter Zijlstra
2017-12-20 15:05         ` Peter Zijlstra
2017-12-21  7:59         ` Vincent Guittot
2017-12-20 14:09   ` Peter Zijlstra
2017-12-20 14:27     ` Vincent Guittot
2017-12-21 10:01       ` Vincent Guittot
2017-12-01 18:01 ` [PATCH v2 2/2] sched/fair: Update blocked load from newly idle balance Brendan Jackman
2017-12-20 14:22   ` Peter Zijlstra
2017-12-21  9:19     ` Dietmar Eggemann

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=20171201180157.18937-1-brendan.jackman@arm.com \
    --to=brendan.jackman@arm.com \
    --cc=dietmar.eggemann@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.