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

* Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> [...] Let's retain our API specifications and backwards compatibilty
> by default. [...]

I agree with you that the 1 second default was a bit too tight - and we
should definitely change that (and it's changed already).

So changing the "allow RT tasks up to 10 seconds uninterrupted CPU
monopolization" is OK to me - it still keeps runaway CPU loops (which
are in the vast majority) debuggable, while allowing common-sense RT
task usage.

But changing that back to the other extreme: "allow lockups by default"
is unreasonable IMO - especially in the face of rtlimit that allows
unprivileged tasks to gain RT privileges.

As an experiment try running a 100% CPU using SCHED_FIFO:99 RT task. It
does not result in a usable Linux system - it interacts with too many
normal system activities. It is a very, very special mode of operation
and anyone using Linux in such a way has to take precautions and has to
tune things specially anyway. (has to turn off the softlockup watchdog,
has to make sure IO requests do not time out artificially, etc.) You
wont even get normal keyboard or console behavior in most cases.

Furthermore, if by "API specifications" you mean POSIX - to get a
conformant POSIX run one has to change a lot of things on a typical
Linux system anyway. APIs and utilities have to be crippled to be "POSIX
compliant".

In other words: we use common sense when thinking about specifications.
The kernel's defaults are about being reasonable by default.

I have no _strong_ feelings about it, but i dont see the practical value
in going beyond 10 seconds - as it turns a rather useful robustness
feature off by default (and keeps it untested, etc.).

Ingo


\
 
 \ /
  Last update: 2008-08-19 15:03    [W:0.143 / U:0.748 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site