Re: a joint letter on low latency and Linux

[Paul Barton-Davis]

Linus writes:

>I refuse to have a kernel that is bogged down with random crap all over
>the place. It's wrong. It's distasteful. And it leads to more and more
>crap over time. That's how you get a BAD operating system.

and later (in a different message) wrote:

>Maybe people in the end can convince me that every single scheduling
>point makes 100% sense, and is not a hack at all but a natural
>thing. Even if that were the case, I'd like to get the thing in
>smaller and explainable pieces..

I'm having a hard time reconciling both of these points of view. Maybe
its just that I'm too philosophical and you're too pragmatic. I can
see 2 possibilities from here:

   1) your revulsion at "random" scheduling points is a really strong
      belief that would likely make convincing you of the value of
      each particular point impossible,

   2) you you accept the idea that there may need to be a bunch of
      "random" scheduling points for this to work, and whilst you
      consider this ugly, you accept that there isn't much of an
      alternative. people will have to have a lot of good numbers
      to convince you to apply a patch that adds a scheduling point.

Do either of these sound like a reasonable summary of your position,
or is there some other precis ?

>flawed. The reason we can't do that ugly thing is also the reason that
>people want to use Linux in the first place. Otherwise you might as well
>run Windows or something else.

Windows is not an option. It doesn't get the job done. If it stays up,
its better than the current Linux kernels for this stuff, but thats
not saying much.

>If it cannot be handled with just a few well-placed things, then it
>shouldn't be handled at all, and you should be working on trying to make
>the UP-threaded kernel work ok, so that for the 2.5.x timeframe we won't
>have this issue any more.

Can someone explain what is meant by getting the UP-threaded kernel to
work ok, and how this would impact scheduling jitter ? If a kernel
thread blocks interrupts for a long time, how can it help to have a
multi-threaded kernel ? My very rough impression is that about 40% of
the required reschedules come from added or pre-existing scheduling
points, and 60% come from a reschedule on return from an interrupt. If
interrupts are disabled, it seems to me as though we are still hosed.

>Live with it.

We can't. *Nobody* will run our apps if the scheduling jitter causes
audio dropouts and lousy live performance response. We can "die" with
it, however.

--p