lkml.org 
[lkml]   [2000]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: a joint letter on low latency and Linux
Date
From
>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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.060 / U:0.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site