Re: Low Latency Patch

[Yoann Vandoorselaere]

Robert Dinse <[e-mail]> writes:

> On Sat, 1 Jul 2000, Khimenko Victor wrote:
> 
> > It's your opinion, not Linus's opinion. I'm REALLY glad Linus has more deep
> > understanding what's crap and what's not. Oh, I forgot: you just want
> > benefits of said patches, you will NOT maintain kernel. Yeah, of course in
> > SUCH case for YOU this patches are very appealing and non-intrusive: all
> > problems caused by hem will be Linus's problems not yours problems. BTW do
> > not mix Solar Designer patch and low latency patch. As Linus said quite a few
> > times some parts of Solar Designer patch like non-executable stack are just
> > "Wrong Things to do"(tm). Some other parts are integrated in kernel... 
> 
>      Linus certainly has a more deep understanding of the OS he created, but
> with respect to what is crap and what is not; that is subjective NOT objective.
> 
>      Part of the reason for making the post again is that I think if people
> realized the more general utility of this, yourself included, they would
> realize it's not just for ME that the patch is very appealing.  I think most
> anybody appreciates a system that responds smoothly and rapidly even under
> extreme load, rather than hurky-jerky which more generally characterizes Linux
> under load. 
> 
>      As far as not mixing the two?  Why not; both are of really more general
> utility than you apparently realize, or are willing to acknowledge.  Both have
> been rejected mainly on asthetic grounds despite their obvious utility.
> 
> > Certainly both of these things affect MUCH more intimate parts of linux
> > kernel then packet radio hacks. And MUCH more dangerous (preemption point in
> > wrong place can easily freeze kernel due to deadlock and non-executable
> > stack... it was beaten to the dead already many times). 
> 
>      They certainly EXPOSE races and deadlock conditions.  But the proper
> approach is the FIX those problems rather than attempting to mask them by
> avoiding calling broken code too often.

Khimenko Victor just explained to you that this patch is broken by design,
so it isn't acceptable on long term.

If you want to start recoding it the right way, feel free to do it,
but do not bother people that know it must not be included 
saying that it should be because it work for you.

Understand that even if it improve things for the user it 
may broke things for the kernel.

-- 
		-- Yoann http://www.mandrakesoft.com/~yoann/
 It is well known that M$ product don't make a free() after a malloc(),
the unix community wish them good luck for their future development.