linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Stefani Seibold <stefani@seibold.net>,
	linux-kernel@vger.kernel.org, mingo@redhat.com
Subject: Re: SCHED_FIFO and SCHED_RR broken by cfs
Date: Mon, 18 Aug 2008 12:50:01 +0200	[thread overview]
Message-ID: <1219056601.10800.306.camel@twins> (raw)
In-Reply-To: <200808172304.50103.nickpiggin@yahoo.com.au>

On Sun, 2008-08-17 at 23:04 +1000, Nick Piggin wrote:
> On Sunday 17 August 2008 00:53, Peter Zijlstra wrote:

> > Has nothing to do with CFS, but everything to do with the fact that we
> > now have a 95% bandwidth control by default.
> >
> > Does doing:
> >
> > echo -1 > /proc/sys/kernel/sched_rt_runtime_us
> >
> > fix it?
> >
> > So, up to 95% cpu usage (per sched_rt_period_us) FIFO and RR behave like
> > they always did, once they cross that line, they'll be throttled.
> >
> > 95% seemed like a sane default in that it leaves a little room to
> > recover from a run-away rt process (esp handy now that !root users can
> > also use RT scheduling classes), and should be enough for most
> > applications as they usually don't consume all that much time.
> 
> Did it seem sane to break POSIX and backwards compatiblity by default?

Up to a point, yes.

There were quite a few complaints that runaway RT tasks could render a
machine unusable - which made 'desktop' usage of the RT class unsafe.

This 95%/1s default allows most RT tasks to run without having to tinker
with the settings, and for those who do need something else, they can
get it too, but will have to turn a knob.

But I guess we could change the default back to unlimited and default to
unsafe if people feel strongly about this.



  reply	other threads:[~2008-08-18 10:49 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-16  9:55 SCHED_FIFO and SCHED_RR broken by cfs Stefani Seibold
2008-08-16 14:53 ` Peter Zijlstra
2008-08-16 16:26   ` Stefani Seibold
2008-08-16 21:29   ` Stefani Seibold
2008-08-17 22:15     ` Dario Faggioli
2008-08-18 10:47       ` [PATCH] sched: rt-bandwidth disable fixes Peter Zijlstra
2008-08-18 11:11         ` Peter Zijlstra
2008-08-17 13:04   ` SCHED_FIFO and SCHED_RR broken by cfs Nick Piggin
2008-08-18 10:50     ` Peter Zijlstra [this message]
2008-08-18 10:58       ` Nick Piggin
2008-08-18 11:09         ` Peter Zijlstra
2008-08-18 11:24           ` Nick Piggin
2008-08-18 11:51             ` Peter Zijlstra
2008-08-18 12:14               ` Nick Piggin
2008-08-18 18:01                 ` Max Krasnyansky
2008-08-18 19:46                   ` Peter Zijlstra
2008-08-19  7:44                   ` Nick Piggin

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=1219056601.10800.306.camel@twins \
    --to=peterz@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=nickpiggin@yahoo.com.au \
    --cc=stefani@seibold.net \
    /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).