Messages in this thread | | | From | "Chris Swiedler" <> | Subject | Low-latency flamewar | Date | Sat, 01 Jul 2000 18:56:15 EDT |
| |
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/
| |