From: Mike Galbraith <efault@gmx.de>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: sched_rt_period_timer causing large latencies
Date: Thu, 05 Apr 2018 10:11:22 +0200 [thread overview]
Message-ID: <1522915882.5593.3.camel@gmx.de> (raw)
In-Reply-To: <20180405174405.175008c7@roar.ozlabs.ibm.com>
On Thu, 2018-04-05 at 17:44 +1000, Nicholas Piggin wrote:
>
> > My method of dealing with the throttle beast from hell for ~big box RT
> > is to stomp it flat during boot, as otherwise jitter is awful.
>
> How do you stomp it flat?
With a size 12 boot originally from SGI. Their extra hairy beasts
tended to grind themselves to fine powder.
---
Documentation/admin-guide/kernel-parameters.txt | 2 ++
kernel/sched/core.c | 11 +++++++++++
2 files changed, 13 insertions(+)
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2788,6 +2788,8 @@
noresume [SWSUSP] Disables resume and restores original swap
space.
+ nortsched [KNL] Disables realtime task bandwidth control.
+
no-scroll [VGA] Disables scrollback.
This is required for the Braillex ib80-piezo Braille
reader made by F.H. Papenmeier (Germany).
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7091,3 +7091,14 @@ const u32 sched_prio_to_wmult[40] = {
};
#undef CREATE_TRACE_POINTS
+
+/*
+ * Bootline option to disable sched_rt_runtime.
+ */
+static int __init parse_nortsched(char *arg)
+{
+ sysctl_sched_rt_runtime = -1;
+ return 0;
+}
+early_param("nortsched", parse_nortsched);
+
> If there could be some basic detection for throttling on a per-CPU
> basis before invoking the best from hell, would that be possible to
> move this out of normal paths?
It's one beast mauling the entire box, that's the problem. I just
consider it a debugging tool, and turn it off (if it kicks in, the RT
game was already over). RT disables RT group scheduling, so I don't
have to care about that evilness.
> Alternatively I think most/all of the RT runtime is coming from
> kernel threads, could they be exempted so this doesn't hit? Although
> it would be sad to suddenly inflict these latencies on someone who
> starts up an RT program :)
Yup, very sad. It should probably become percpu.
-Mike
next prev parent reply other threads:[~2018-04-05 8:11 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-04 23:11 sched_rt_period_timer causing large latencies Nicholas Piggin
2018-04-05 6:46 ` Mike Galbraith
2018-04-05 7:44 ` Nicholas Piggin
2018-04-05 8:11 ` Mike Galbraith [this message]
2018-04-05 8:27 ` Peter Zijlstra
2018-04-05 8:40 ` Mike Galbraith
2018-04-05 10:08 ` Nicholas Piggin
2018-04-05 10:44 ` Nicholas Piggin
2018-04-06 16:23 ` Peter Zijlstra
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=1522915882.5593.3.camel@gmx.de \
--to=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@gmail.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.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