Re: a joint letter on low latency and Linux

[Larry McVoy]

> Although there is an argument that some of the later patches went too
> far (e.g. adding code to spinlock functions), I think that the basic
> structure of your code (not the source, but the notion of adding
> preemption points at locations that were identifiable problems in
> linux' latency behaviour) was thought by several people to be a good
> solution. Everything I have read from Linus has suggested to me
> that he thinks that this is a bad way to solve the latency issues. 

I'm coming into this a little late but here's my take on all of this.
I have a little background on this, I was asked to support this letter
by using LMbench to "show" that there were no problems with the Ingo
patches and declined.  I felt that what I was asked to do was misleading
and I didn't agree with what was in the letter.

Paul and the others in favor of the low latency fixes are fond of pointing
out that they must be good because this is how IRIX and BeOS solve the
problem.  That's never a good reason to do anything - fortunately for
all of us, Linus evaluates things on their technical merits.  And "IRIX
does it" has no technical merit whatsoever.

I and others have pointed out that if you need hard real time then
what you do is use RT Linux and you can get exactly what you need.
I've heard two arguments against this:

a) ``Other operating systems offer "soft realtime" and we don't want to
   port our code from that to the RT Linux model.''  Translation:
   ``other operating systems have made poor design decisions, let's try
   and pressure Linus into doing the same thing with Linux.''  That's a
   poor approach to the problem.  Just saying that NT does it does not
   make it right.  Linux has a large, quickly growing, market share.
   In my opinion, it is better to do the right thing, wait until Linux is
   the market leader, and then laugh at the screwed up systems that made
   the wrong choices.  Screwing up Linux so it has the same problems that
   other systems have in the name of portablility is not the Linux way.

b) ``If we take the RT Linux path then Linus will never add the low latency
   features we want.''  I love this argument.  It implies knowledge that there
   is a better way, that if you use the better way then there is no need to do
   what Linus doesn't really want to do.  Exactly.

In fairness to the low latency application people, I think that the
RT Linux folks need to provide skeleton "apps" that show how to solve
problems in the RT Linux space.  Whether that happens or not, the RT Linux
approach is really brilliant and it is the right approach to the problem
space, and I'm more than a little sick of hearing people avoid using it.
Get with the program, folks, use the best tool for the job.  No matter
what Ingo does, it is a _fact_ that you can not get both good performance
for a multi user time sharing operating system and real time applications.

Please understand that it might be that some of Ingo's work is a good
thing and that it will go into the kernel.  I am not sure about that
one way or the other.  What I am sure about is that putting features
into the kernel for the benefit of real time applications is a slippery
slope that just leads to bad change on top of bad change.  It effects
the scheduler, the I/O paths, the interrupt handling, and probably a
bunch of other places I'm forgetting.  The changes are at direct odds
with time sharing performance and the proponents of the changes will
argue each one in isolation, rather than looking at the effects of all
of them.  

My advice, heeded or not, is to just say no.  We have an excellent answer
for realtime, it's called RT Linux.  Go use it - it's better than any
other answer.