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: <1219057765.10800.315.camel@twins>
Date:	Mon, 18 Aug 2008 13:09:25 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Nick Piggin <nickpiggin@...oo.com.au>
Cc:	"Torvalds, Linus" <torvalds@...ux-foundation.org>,
	Stefani Seibold <stefani@...bold.net>,
	linux-kernel@...r.kernel.org, mingo@...hat.com
Subject: Re: SCHED_FIFO and SCHED_RR broken by cfs

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.

> 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.

> > 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.



--
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/