lkml.org 
[lkml]   [2000]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectLow-latency flamewar
Date
Is anyone listening to what Linus is saying in the "joint letter on low 
latency and Linux" thread? If so, why is there still a flamewar going on
over this?

>I'm fully aware of the fact that Linux needs improvment in this
>area. I've tried to explain that my beef with the low-latency patches has
>never been that I don't believe it is a worthy goal. It's just that I also
>firmly believe that there are right ways of doing this. Without ugly
>patches that add random stuff to random places.

The only problem Linus has over Ingo's low-latency patches is that they were
rescheduling calls put in simply to make a single benchmark test run
faster--something that he has said many times before is a stupid thing to
do. He agrees that a reschedule call needs to go into the copy_from_user()
code:

>I'd be quite happy to apply the copy_to/from_user() part, for example, and
>then let's see what the other problem-spots are, and how they should be
>properly fixed. The copy_to/from_user() case is quite simple to
>understand, and there really aren't that many alternatives to handling it.

simply because the code obviously needs it, and it's not just stuck in
blindly because a benchmark would run faster. Furthermore, in regard to the
argument over whether pro-audio needs RTLinux or not, he says explicitly:

>In many cases I just think that RTLinux is a worse fix than the disease. I
>think RTLinux is perfect for those things that truly need latency
>guarantees: no OS at _all_ in the way. But using it for "normal" stuff
>like just streaming audio and video is overkill.

In those three posts, he points out exactly how to solve the problem. Just
Use The Source (tm) to figure out where we need to reduce latency problems.
The audio people are convinced that they only need around 1 or 2 orders of
magnitude _worst-case_ improvement (100ms to 5ms) to run perfectly fine, and
don't need RTLinux's usec latency OR mission-critical hard-time guarantees.

So to end this whole stupid flamewar, all we have to do is look at the code
and find a _few_ places where we can easily and obviously reduce latency.
Start with the copy_to/from_user() code. Maybe through a huge coincidence,
the places we _decide_ to put in reschedule calls will be exactly the same
places Ingo already put them in:

>Maybe people in the end can convince me that every single
>scheduling point [in Ingo's patch] makes 100% sense, and is not a hack at
>all but a natural thing.

But then we'll _know_ why we put them there.

Linus's voice isn't (quite) the word of God, but when he's explaining
_exactly_ what we need to do to fix the problem, I think it would behoove us
to listen...

chris
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com


-
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.057 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site