Messages in this thread | | | Subject | Re: a joint letter on low latency and Linux | Date | Sun, 02 Jul 2000 14:34:36 -0400 | From | Paul Barton-Davis <> |
| |
>Yeah. You are 100% right. "Kernel has to be fixed, not just telling people >that a patch exists". And thus someone should step up and develop fix for >kernel alongside with paper (or .txt, .html or even .doc file - not such a >big difference) where it's explained WHY this solution WILL fix problem.
The past history of Linux kernel development doesn't look anything like this. it looks like people coming up with solutions that are accepted, or rejected. in this case someone came up with a solution and it was not accepted. so a bunch of other people wrote to try to clarify the design space that an acceptable solution would have to fit into, precisely to avoid having to deal with non-acceptance all over again.
>PB> The problem is: Linux DOESN'T work unless its OK for your >PB> not-too-far-from-1GHz processor to sit around and twiddle its thumbs >PB> for 10s of msecs while chunks of code that made it through the filters >PB> of this list screw around with lengthy codepaths, spinlocks and IRQs. > >It's bad but acceptable for millions of users. If it's unacceptable for you
It would be more informative, to say that it works for an entire *class* of users whose numbers are currently in the millions.
It doesn't work at all for various other classes of users, whose numbers are much smaller, but a solution for them would probably benefit a substantial number of the existing user base as well (based on feedback with Ingo's patches to date).
>then you should develop solution (or hire someone who will do such thing for >you).
I don't need to do that because somebody already did (Ingo).
And what you don't seem to understand is that "a solution" for me is not entirely a technical matter. I have an LL-patched kernel on machine, and I can use it anytime I want to. What I can't do with the "patch" approach is to convince any of the many companies and individuals who want to jettison Windows and MacOS to pay serious attention to Linux.
The problem is that many people here, including Linus, and to some extent Ingo himself, don't like the solution that exists today. At the same time, various people have insisted "the only solution to this is hard real-time support" in more or less the same breath that they've said "hard real-time should never be part of the Linux kernel".
So, what's the take home story from that pair of statements ? The most optimistic I can construct is "we'll accept some changes that reduce the real hogs down to a reasonable range by comparison with the rest of the system, but if thats not good enough, too bad. This ain't a niche OS like BeOS, you know."
I'll just cross my fingers that the obvious hogs from Andrew Mortons latency profiler will get fixed, and that this will move us closer to acceptable latency performance.
--p
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |