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]

Date:	Thu, 28 Aug 2008 21:39:07 +0200
From:	Stefani Seibold <stefani@...bold.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Mark Hounschell <markh@...pro.net>,
	Steven Rostedt <rostedt@...dmis.org>,
	Nick Piggin <nickpiggin@...oo.com.au>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	LKML <linux-kernel@...r.kernel.org>,
	Dario Faggioli <raistlin@...ux.it>,
	Max Krasnyansky <maxk@...lcomm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 6/6] sched: disabled rt-bandwidth by default

I started this discussion last week with an apparent bug in the new CFS.

As it turns out, it was not a bug, it was an feature, a (undocumented?)
feature.

In the world of embeded device and real time programming it is not a
hard job to compile the kernel right for the desired usage und fix the
startup script to use the desired policy.

Getting back the old behaviour would be nice and in my opinion the right
way, because the new one breaks with POSIX. But I have a working
solution and that is for me what matters.

By the way - RT means not hard real time. Hard-RT is a marketing phrase.
A given combination of OS and hardware must handle a event in a given
time. Thats all.

Thanks for the support.

Regards,
Stefani, the hard RT "real woman" programmer ;-)

Am Donnerstag, den 28.08.2008, 11:42 -0700 schrieb Linus Torvalds:
> 
> On Thu, 28 Aug 2008, Mark Hounschell wrote:
> > 
> > More and more are wanting and now finding the Linux kernel to be more
> > RT capable. I seem to remember way back you saying it was one thing you didn't
> > really care much about one way or the other. Thats OK. But, you _are_ the man.
> 
> The thing is, the reason I dislike RT is that so many people have so 
> different understanding of what RT means.
> 
> Quite frankly, I think that the people who are complaining (like you) 
> think that RT means "hard realtime". You think about literally specialized 
> devices.
> 
> A lot of _other_ people think that RT means "good audio latency", where it 
> really is a lot softer. 
> 
> And neither camp seems to ever admit that they are just a small camp, and 
> that the other camp exists or is even valid.
> 
> 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.
> 
> As to your
> 
> > "just to protect a few _supposedly_ bad programmers???"
> 
> 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.
> 
> 		Linus
> 

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