Re: SCHED_FIFO and SCHED_RR broken by cfs

[Nick Piggin]

On Monday 18 August 2008 21:09, Peter Zijlstra wrote:
> On Mon, 2008-08-18 at 20:58 +1000, Nick Piggin wrote:
> > On Monday 18 August 2008 20:50, Peter Zijlstra wrote:
> > > 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.
> >
> > Right, but it is restricted to root, and if the task is run as root
> > then it can equally break the system in any number of ways. So the
> > complaints are just wrong.
>
> Not so, we have RLIMIT_RTPRIO and quite a few people using it.

OK, but it's the same as any privilige granted. You have to be careful
with it.

TBH, it's pretty trivial to write a watchdog process in your RT app.
Actually, many *real* RT applications use one in order to help with
failover/failstop/etc. and I expect _all_ non trivial ones should be
using a watchdog when under development or running in a debugging
mode.


> > I have no problems with having some non-default mode to throttle by
> > default. And we already have the sysrq which can downgrade RT tasks.
>
> Yeah - except that most distros disable sysrq and not a single desktop
> user knows about it.

What are they doing writing RT apps then?


> > > 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.
> >
> > And that could also easily cause huge problems for code that does the
> > *right* thing.
> >
> > > But I guess we could change the default back to unlimited and default
> > > to unsafe if people feel strongly about this.
> >
> > Yes, you can't just break the API like this. Please do fix.
>
> Sigh - I guess that means all distros will just set a limit in their
> init scripts - leaving those above in the same situation.

Really, you think the enterprise distros will willingly break POSIX
and their own backwards compatiblity by default? I wouldn't have
thought so, but anyway I guess they are free to make that choice, so
where's the problem?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/