linux-kernel - Re: SCHED_FIFO and SCHED

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200808182058.07346.nickpiggin@yahoo.com.au>
Date:	Mon, 18 Aug 2008 20:58:07 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Peter Zijlstra <peterz@...radead.org>,
	"Torvalds, Linus" <torvalds@...ux-foundation.org>
Cc:	Stefani Seibold <stefani@...bold.net>,
	linux-kernel@...r.kernel.org, mingo@...hat.com
Subject: Re: SCHED_FIFO and SCHED_RR broken by cfs

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.

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.


> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/