linux-kernel - Re: [PATCH 6/6] sched: disabled rt-bandwidth by default

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: <48AB0DB6.9060802@qualcomm.com>
Date:	Tue, 19 Aug 2008 11:15:18 -0700
From:	Max Krasnyansky <maxk@...lcomm.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Nick Piggin <nickpiggin@...oo.com.au>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	linux-kernel@...r.kernel.org,
	Stefani Seibold <stefani@...bold.net>,
	Dario Faggioli <raistlin@...ux.it>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 6/6] sched: disabled rt-bandwidth by default

Ingo Molnar wrote:
> * Nick Piggin <nickpiggin@...oo.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.) 
btw The tuning is actually very easy and straightforward ie not so 
special anymore. That's one of the use cases that my cpu isolation work 
was addressing. 2.6.27 will have most of the mechanisms available. All 
the tuning is done by the 'syspart' package:
http://git.kernel.org/?p=linux/kernel/git/maxk/syspart.git;a=summary

> You wont even get normal keyboard or console behavior in most cases.
Only on a single processor system.

> 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.).
Same here. I do not mind setting sysctls. At the same time I agree with 
Nick that ideally we should not change the meaning of SCHED_FIFO.

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