|From:||Alan Cox <alan-AT-lxorguk.ukuu.org.uk>|
|To:||Linus Torvalds <torvalds-AT-linux-foundation.org>|
|Subject:||Re: [PATCH 6/6] sched: disabled rt-bandwidth by default|
|Date:||Thu, 28 Aug 2008 21:53:21 +0100|
|Cc:||Mark Hounschell <markh-AT-compro.net>, Steven Rostedt <rostedt-AT-goodmis.org>, Nick Piggin <nickpiggin-AT-yahoo.com.au>, Ingo Molnar <mingo-AT-elte.hu>, Peter Zijlstra <a.p.zijlstra-AT-chello.nl>, LKML <linux-kernel-AT-vger.kernel.org>, Stefani Seibold <stefani-AT-seibold.net>, Dario Faggioli <raistlin-AT-linux.it>, Max Krasnyansky <maxk-AT-qualcomm.com>, Thomas Gleixner <tglx-AT-linutronix.de>, Andrew Morton <akpm-AT-linux-foundation.org>|
> And I'm not really interested. Quite frankly, I suspect the "we want to > run something like pulseaudio with RT priorities" camp is the more common > one, and in that context I understand limiting SCHED_FIFO sounds perfectly > understandable. Is there actually a reason we can't have two forms of SCHED_FIFO. For hard RT the existing behaviour is a lot more useful and it is hard to see how you'd emulate it. > quite frankly, most programmers aren't "supposedly bad". And if you think > that the hard-RT "real man" programmers aren't bad, I really have nothing > to say. "real man" programmers stare at the code in Zen contemplation and debug by powercycling - thats one thing even hard RT processes can't beat. Alan
Copyright © 2008, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds