[lkml]   [2008]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 6/6] sched: disabled rt-bandwidth by default

* Peter Zijlstra <> wrote:

> Disable bandwidth control by default.
> Signed-off-by: Peter Zijlstra <>
> ---
> kernel/sched.c | 17 +++++++----------
> 1 file changed, 7 insertions(+), 10 deletions(-)
> Index: linux-2.6/kernel/sched.c
> ===================================================================
> --- linux-2.6.orig/kernel/sched.c
> +++ linux-2.6/kernel/sched.c
> @@ -824,9 +824,9 @@ static __read_mostly int scheduler_runni
> /*
> * part of the period that we allow rt tasks to run in us.
> - * default: 0.95s
> + * default: inf
> */
> -int sysctl_sched_rt_runtime = 950000;
> +int sysctl_sched_rt_runtime = -1;

The fixes look good to me, but this enabling of infinite RT task lockups
is not an improvement.

The thing is, i got far more bugreports about locked up RT tasks where
the lockup was unintentional, than real bugreports about anyone
_intending_ for the whole box to come to a grinding halt because a
high-prio RT tasks is monopolizing the CPU.

In fact there's only been this artificial test so far.

So could you please just increase the chunking to 10 seconds or so, from
the current 1 second? Anyone locking up the system for more than 10
seconds via an RT task has to deal with many other issues already.

I.e. keep the system borderline debuggable (up to 10 seconds delays are
_not_ nice so people will notice) - but it's still a marked improvement
from completly locked up desktops.

And those who really need longer than 10 second periods can set it
higher, or even (if they want to live dangerously or run POSIX
conformance tests) make it infinite (set it to -1) - and will have to
deal with other things like the softlockup watchdog as well.



 \ /
  Last update: 2008-08-19 13:09    [W:0.123 / U:1.072 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site