public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mike Galbraith <efault@gmx.de>
To: Ani <asinha@zeugmasystems.com>
Cc: Lucas De Marchi <lucas.de.marchi@gmail.com>,
	linux-kernel@vger.kernel.org,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Ingo Molnar <mingo@elte.hu>
Subject: Re: question on sched-rt group allocation cap: sched_rt_runtime_us
Date: Sun, 06 Sep 2009 08:32:59 +0200	[thread overview]
Message-ID: <1252218779.6126.17.camel@marge.simson.net> (raw)
In-Reply-To: <36bbf267-be27-4c9e-b782-91ed32a1dfe9@g1g2000pra.googlegroups.com>

On Sat, 2009-09-05 at 19:32 -0700, Ani wrote: 
> On Sep 5, 3:50 pm, Lucas De Marchi <lucas.de.mar...@gmail.com> wrote:
> >
> > Indeed. I've tested this same test program in a single core machine and it
> > produces the expected behavior:
> >
> > rt_runtime_us / rt_period_us     % loops executed in SCHED_OTHER
> > 95%                              4.48%
> > 60%                              54.84%
> > 50%                              86.03%
> > 40%                              OTHER completed first
> >
> 
> Hmm. This does seem to indicate that there is some kind of
> relationship with SMP. So I wonder whether there is a way to turn this
> 'RT bandwidth accumulation' heuristic off.

No there isn't, but maybe there should be, since this isn't the first
time it's come up.  One pro argument is that pinned tasks are thoroughly
screwed when an RT hog lands on their runqueue.  On the con side, the
whole RT bandwidth restriction thing is intended (AFAIK) to allow an
admin to regain control should RT app go insane, which the default 5%
aggregate accomplishes just fine.

Dunno.  Fly or die little patchlet (toss). 

sched: allow the user to disable RT bandwidth aggregation.

Signed-off-by: Mike Galbraith <efault@gmx.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 8736ba1..6e6d4c7 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1881,6 +1881,7 @@ static inline unsigned int get_sysctl_timer_migration(void)
 #endif
 extern unsigned int sysctl_sched_rt_period;
 extern int sysctl_sched_rt_runtime;
+extern int sysctl_sched_rt_bandwidth_aggregate;
 
 int sched_rt_handler(struct ctl_table *table, int write,
 		struct file *filp, void __user *buffer, size_t *lenp,
diff --git a/kernel/sched.c b/kernel/sched.c
index c512a02..ca6a378 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -864,6 +864,12 @@ static __read_mostly int scheduler_running;
  */
 int sysctl_sched_rt_runtime = 950000;
 
+/*
+ * aggregate bandwidth, ie allow borrowing from neighbors when
+ * bandwidth for an individual runqueue is exhausted.
+ */
+int sysctl_sched_rt_bandwidth_aggregate = 1;
+
 static inline u64 global_rt_period(void)
 {
 	return (u64)sysctl_sched_rt_period * NSEC_PER_USEC;
diff --git a/kernel/sched_rt.c b/kernel/sched_rt.c
index 2eb4bd6..75daf88 100644
--- a/kernel/sched_rt.c
+++ b/kernel/sched_rt.c
@@ -495,6 +495,9 @@ static int balance_runtime(struct rt_rq *rt_rq)
 {
 	int more = 0;
 
+	if (!sysctl_sched_rt_bandwidth_aggregate)
+		return 0;
+
 	if (rt_rq->rt_time > rt_rq->rt_runtime) {
 		spin_unlock(&rt_rq->rt_runtime_lock);
 		more = do_balance_runtime(rt_rq);
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index cdbe8d0..0ad08e5 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -368,6 +368,14 @@ static struct ctl_table kern_table[] = {
 	},
 	{
 		.ctl_name	= CTL_UNNUMBERED,
+		.procname	= "sched_rt_bandwidth_aggregate",
+		.data		= &sysctl_sched_rt_bandwidth_aggregate,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= &sched_rt_handler,
+	},
+	{
+		.ctl_name	= CTL_UNNUMBERED,
 		.procname	= "sched_compat_yield",
 		.data		= &sysctl_sched_compat_yield,
 		.maxlen		= sizeof(unsigned int),



  reply	other threads:[~2009-09-06  6:33 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <dgRNo-3uc-5@gated-at.bofh.it>
     [not found] ` <dhb9j-1hp-5@gated-at.bofh.it>
     [not found]   ` <dhcf5-263-13@gated-at.bofh.it>
2009-09-06  2:32     ` question on sched-rt group allocation cap: sched_rt_runtime_us Ani
2009-09-06  6:32       ` Mike Galbraith [this message]
2009-09-06 10:18         ` Mike Galbraith
     [not found]           ` <DDFD17CC94A9BD49A82147DDF7D545C54DC482@exchange.ZeugmaSystems.local>
2009-09-06 15:09             ` Mike Galbraith
2009-09-07  0:41               ` Anirban Sinha
     [not found]               ` <1252311463.7586.26.camel@marge.simson.net>
2009-09-07 11:06                 ` [rfc] lru_add_drain_all() vs isolation Peter Zijlstra
2009-09-07 13:35                   ` Oleg Nesterov
2009-09-07 13:53                     ` Peter Zijlstra
2009-09-07 14:18                       ` Oleg Nesterov
2009-09-07 14:25                         ` Peter Zijlstra
2009-09-07 23:56                   ` KOSAKI Motohiro
2009-09-08  8:20                     ` Peter Zijlstra
2009-09-08 10:06                       ` KOSAKI Motohiro
2009-09-08 10:20                         ` Peter Zijlstra
2009-09-08 11:41                           ` KOSAKI Motohiro
2009-09-08 12:05                             ` Peter Zijlstra
2009-09-08 14:03                               ` Christoph Lameter
2009-09-08 14:20                                 ` Peter Zijlstra
2009-09-08 15:22                                   ` Christoph Lameter
2009-09-08 15:27                                     ` Peter Zijlstra
2009-09-08 15:32                                     ` Christoph Lameter
2009-09-09  4:27                                       ` KOSAKI Motohiro
2009-09-09 14:08                                         ` Christoph Lameter
2009-09-09 23:43                                           ` KOSAKI Motohiro
2009-09-10 18:03                                             ` Christoph Lameter
2009-09-09 15:39                                         ` Minchan Kim
2009-09-09 16:18                                           ` Lee Schermerhorn
2009-09-09 16:46                                             ` Minchan Kim
2009-09-09 23:58                                           ` KOSAKI Motohiro
2009-09-10  1:00                                             ` Minchan Kim
2009-09-10  1:15                                               ` KOSAKI Motohiro
2009-09-10  1:23                                                 ` Minchan Kim
2009-09-09  2:06                               ` KOSAKI Motohiro
     [not found]         ` <DDFD17CC94A9BD49A82147DDF7D545C54DC483@exchange.ZeugmaSystems.local>
     [not found]           ` <DDFD17CC94A9BD49A82147DDF7D545C54DC485@exchange.ZeugmaSystems.local>
2009-09-07  0:28             ` question on sched-rt group allocation cap: sched_rt_runtime_us Anirban Sinha
2009-09-07  6:54           ` Mike Galbraith
     [not found]             ` <DDFD17CC94A9BD49A82147DDF7D545C54DC489@exchange.ZeugmaSystems.local>
2009-09-08  7:10               ` Anirban Sinha
2009-09-08  9:26                 ` Mike Galbraith
2009-09-07  7:59         ` Peter Zijlstra
2009-09-07  8:24           ` Mike Galbraith
     [not found]           ` <DDFD17CC94A9BD49A82147DDF7D545C54DC487@exchange.ZeugmaSystems.local>
2009-09-08  7:08             ` Anirban Sinha
2009-09-08  8:42               ` Peter Zijlstra
2009-09-08 14:41                 ` Anirban Sinha
     [not found]         ` <DDFD17CC94A9BD49A82147DDF7D545C54DC48B@exchange.ZeugmaSystems.local>
2009-09-08 17:41           ` Anirban Sinha
2009-09-08 19:06             ` Mike Galbraith
2009-09-08 19:34               ` Anirban Sinha
2009-09-09  4:10                 ` Mike Galbraith
2009-09-05 17:13 Anirban Sinha
     [not found] <Acotv57vW6nkRxQOQLuBf8W5yfJIlwAAtMAw>
2009-09-05  0:55 ` Anirban Sinha
2009-09-05 17:43   ` Lucas De Marchi
2009-09-05 20:40   ` Fabio Checconi
2009-09-05 22:40     ` Lucas De Marchi
     [not found]     ` <DDFD17CC94A9BD49A82147DDF7D545C54DC481@exchange.ZeugmaSystems.local>
2009-09-06  0:47       ` Anirban Sinha
2009-09-06 13:21         ` Fabio Checconi
     [not found]           ` <DDFD17CC94A9BD49A82147DDF7D545C54DC484@exchange.ZeugmaSystems.local>
2009-09-07  0:26             ` Anirban Sinha
2009-09-08 17:26           ` Anirban Sinha
2009-09-08 21:37             ` Anirban Sinha

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=1252218779.6126.17.camel@marge.simson.net \
    --to=efault@gmx.de \
    --cc=a.p.zijlstra@chello.nl \
    --cc=asinha@zeugmasystems.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lucas.de.marchi@gmail.com \
    --cc=mingo@elte.hu \
    /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