From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Ingo Molnar <mingo@elte.hu>
Cc: Paul Mackerras <paulus@samba.org>,
Corey Ashford <cjashfor@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org,
Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: [PATCH 1/7] sched: rt: document the risk of small values in the bandwidth settings
Date: Tue, 05 May 2009 17:50:21 +0200 [thread overview]
Message-ID: <20090505155436.863098054@chello.nl> (raw)
In-Reply-To: 20090505155020.309162852@chello.nl
[-- Attachment #1: sched-rt-docu.patch --]
[-- Type: text/plain, Size: 2062 bytes --]
Thomas noted that we should disallow sysctl_sched_rt_runtime == 0 for (!
RT_GROUP) since the root group always has some RT tasks in it.
Further, update the documentation to inspire clue.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
---
Documentation/scheduler/sched-rt-group.txt | 18 ++++++++++++++++++
kernel/sched.c | 7 +++++++
2 files changed, 25 insertions(+)
Index: linux-2.6/Documentation/scheduler/sched-rt-group.txt
===================================================================
--- linux-2.6.orig/Documentation/scheduler/sched-rt-group.txt
+++ linux-2.6/Documentation/scheduler/sched-rt-group.txt
@@ -4,6 +4,7 @@
CONTENTS
========
+0. WARNING
1. Overview
1.1 The problem
1.2 The solution
@@ -14,6 +15,23 @@ CONTENTS
3. Future plans
+0. WARNING
+==========
+
+ Fiddling with these settings can result in an unstable system, the knobs are
+ root only and assumes root knows what he is doing.
+
+Most notable:
+
+ * very small values in sched_rt_period_us can result in an unstable
+ system when the period is smaller than either the available hrtimer
+ resolution, or the time it takes to handle the budget refresh itself.
+
+ * very small values in sched_rt_runtime_us can result in an unstable
+ system when the runtime is so small the system has difficulty making
+ forward progress (NOTE: the migration thread and kstopmachine both
+ are real-time processes).
+
1. Overview
===========
Index: linux-2.6/kernel/sched.c
===================================================================
--- linux-2.6.orig/kernel/sched.c
+++ linux-2.6/kernel/sched.c
@@ -10024,6 +10024,13 @@ static int sched_rt_global_constraints(v
if (sysctl_sched_rt_period <= 0)
return -EINVAL;
+ /*
+ * There's always some RT tasks in the root group
+ * -- migration, kstopmachine etc..
+ */
+ if (sysctl_sched_rt_runtime == 0)
+ return -EBUSY;
+
spin_lock_irqsave(&def_rt_bandwidth.rt_runtime_lock, flags);
for_each_possible_cpu(i) {
struct rt_rq *rt_rq = &cpu_rq(i)->rt;
--
next prev parent reply other threads:[~2009-05-05 16:20 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-05 15:50 [PATCH 0/7] pending sched and perf_counter patches Peter Zijlstra
2009-05-05 15:50 ` Peter Zijlstra [this message]
2009-05-05 18:33 ` [tip:sched/core] sched: rt: document the risk of small values in the bandwidth settings tip-bot for Peter Zijlstra
2009-05-05 15:50 ` [PATCH 2/7] perf_counter: uncouple data_head updates from wakeups Peter Zijlstra
2009-05-05 18:34 ` [tip:perfcounters/core] " tip-bot for Peter Zijlstra
2009-05-05 15:50 ` [PATCH 3/7] perf_counter: ioctl(PERF_COUNTER_IOC_RESET) Peter Zijlstra
2009-05-05 18:31 ` Corey Ashford
2009-05-05 18:42 ` Peter Zijlstra
2009-05-05 19:31 ` Ingo Molnar
2009-05-05 18:34 ` [tip:perfcounters/core] perf_counter: add ioctl(PERF_COUNTER_IOC_RESET) tip-bot for Peter Zijlstra
2009-05-05 15:50 ` [PATCH 4/7] perf_counter: provide an mlock threshold Peter Zijlstra
2009-05-05 18:34 ` [tip:perfcounters/core] " tip-bot for Peter Zijlstra
2009-05-05 15:50 ` [PATCH 5/7] perf_counter: fix the output lock Peter Zijlstra
2009-05-05 18:34 ` [tip:perfcounters/core] " tip-bot for Peter Zijlstra
2009-05-05 15:50 ` [PATCH 6/7] perf_counter: inheritable sample counters Peter Zijlstra
2009-05-05 18:34 ` [tip:perfcounters/core] " tip-bot for Peter Zijlstra
2009-05-05 15:50 ` [PATCH 7/7] perf_counter: tools: update the tools to support process and inherited counters Peter Zijlstra
2009-05-05 18:34 ` [tip:perfcounters/core] " tip-bot for 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=20090505155436.863098054@chello.nl \
--to=a.p.zijlstra@chello.nl \
--cc=cjashfor@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.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.