linux-rt-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Scott Wood <swood@redhat.com>
To: Steven Rostedt <rostedt@goodmis.org>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Vincent Guittot <vincent.guittot@linaro.org>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Rik van Riel <riel@surriel.com>, Mel Gorman <mgorman@suse.de>,
	linux-kernel@vger.kernel.org,
	linux-rt-users <linux-rt-users@vger.kernel.org>
Subject: [RFC PATCH 0/3] newidle_balance() latency mitigation
Date: Tue, 28 Apr 2020 00:02:39 -0500	[thread overview]
Message-ID: <20200428050242.17717-1-swood@redhat.com> (raw)

These patches mitigate latency caused by newidle_balance() on large
systems, by enabling interrupts when the lock is dropped, and exiting
early at various points if an RT task is runnable on the current CPU.

When applied to an RT kernel on a 72-core machine (2 threads per core), I
saw significant reductions in latency as reported by rteval -- from
over 500us to around 160us with hyperthreading disabled, and from
over 1400us to around 380us with hyperthreading enabled.

This isn't the first time something like this has been tried:
https://lore.kernel.org/lkml/20121222003019.433916240@goodmis.org/
That attempt ended up being reverted:
https://lore.kernel.org/lkml/5122CD9C.9070702@oracle.com/

The problem in that case was the failure to keep BH disabled, and the
difficulty of fixing that when called from the post_schedule() hook. 
This patchset uses finish_task_switch() to call newidle_balance(), which
enters in non-atomic context so we have full control over what we disable
and when.

There was a note at the end about wanting further discussion on the matter --
does anyone remember if that ever happened and what the conclusion was?
Are there any other issues with enabling interrupts here and/or moving
the newidle_balance() call?

Rik van Riel (1):
  sched,rt: break out of load balancing if an RT task appears

Scott Wood (2):
  sched/fair: Call newidle_balance() from finish_task_switch()
  sched/fair: Enable interrupts when dropping lock in newidle_balance()

 kernel/sched/core.c  |  7 +++--
 kernel/sched/fair.c  | 72 +++++++++++++++++++++++---------------------
 kernel/sched/sched.h | 12 +++++---
 3 files changed, 49 insertions(+), 42 deletions(-)

-- 
2.18.2


             reply	other threads:[~2020-04-28  5:02 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-28  5:02 Scott Wood [this message]
2020-04-28  5:02 ` [RFC PATCH 1/3] sched/fair: Call newidle_balance() from finish_task_switch() Scott Wood
2020-04-28 21:37   ` Valentin Schneider
2020-04-28 22:09     ` Peter Zijlstra
2020-04-28 22:55       ` Scott Wood
2020-04-28 23:02         ` Peter Zijlstra
2020-04-28 23:20           ` Scott Wood
2020-04-29  9:05             ` Peter Zijlstra
2020-04-30  1:31               ` Scott Wood
2020-05-11 10:58                 ` Peter Zijlstra
2020-05-11 12:13                   ` Peter Zijlstra
2020-04-28 22:33     ` Scott Wood
2020-04-29 12:00       ` Valentin Schneider
2020-04-29  8:27   ` Vincent Guittot
2020-04-30  1:36     ` Scott Wood
2020-04-28  5:02 ` [RFC PATCH 2/3] sched/fair: Enable interrupts when dropping lock in newidle_balance() Scott Wood
2020-04-28  5:02 ` [RFC PATCH 3/3] sched,rt: break out of load balancing if an RT task appears Scott Wood
2020-04-28 21:56   ` Valentin Schneider
2020-04-28 22:33     ` Scott Wood
2020-04-28 22:52       ` Scott Wood
2020-04-29 12:01       ` Valentin Schneider
2020-04-28 13:27 ` [RFC PATCH 0/3] newidle_balance() latency mitigation Steven Rostedt
2020-04-29 23:13 ` Valentin Schneider
2020-04-30  7:44   ` Vincent Guittot
2020-04-30 10:14     ` Valentin Schneider
2020-04-30 12:42       ` Vincent Guittot
2020-04-30 13:56         ` Valentin Schneider
2020-04-30 12:48 ` 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=20200428050242.17717-1-swood@redhat.com \
    --to=swood@redhat.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=riel@surriel.com \
    --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;
as well as URLs for NNTP newsgroup(s).