Re: Low Latency Patch

[Robert Dinse]

On Sat, 1 Jul 2000, Khimenko Victor wrote:
> 
> Linus tried it. You did not listen. Now we need to try other approach :-)

     I would be happy to argue the merits or lack thereof of including this in
the main kernel tree.  I've read Linus's letter; and I understand it's his
puppy and ultimately he makes the decisions.  However; I don't see how that
justifies abuse on your part and it's not conducive to an intelligent
discussion. 

     If the Linux development community is not responsive to the end user
community, refusing to incorporate necessary functionality on the basis of
aesthetics, then that community will abandon Linux in favor of something else. 
Is that really what you want? 

     The reason for my original post is that I wanted people to realize this
had utility even for people without special applications that require low
latency; it makes the system operate considerably more pleasantly under load.
I suspect if more people try it, more people are going to find it worthwhile.

     I avoided products from M$ because of attitudes like yours.  If this
becomes the norm for Linux as well, then I guess I'll need to start looking at
different OS's, again.  But I think you just represent a vocal abusive
individual, and not the mainstream development community.

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

> RD>      Personally, I would be thrilled if Linux were just stable on Sparc-32 SMP
> RD> platforms but that's another issue.
> 
> And patches like mentioned above is way to make it LESS stable on you great
> Sparc-32 SMP platform, not more stable.

     This is true, they do; but again, fixing the broken code rather than avoid
calling it too frequently is the proper approach.