Messages in this thread | | | Date | Fri, 23 Jul 1999 18:50:03 -0500 (CDT) | From | Oliver Xymoron <> | Subject | Re: real-time threaded IO with low latency (audio) |
| |
On Fri, 23 Jul 1999, Ingo Molnar wrote:
> On Fri, 23 Jul 1999, Sam Roberts wrote: > > > Sorry. If it gets your job done, great! I just think its an unfortunate > > limitation of Linux. That Linux is optimized for throughput is great > > for servers, and thats important. For personal workstations I don't think > > its great. [...] > > hm, you havent been following Linux development for too long, have you? > Latency was always the primary optimization target, bandwith the second.
Exactly. But it has never been intended to be a realtime system in the true sense of the word. Nor is that something we want to aim for. Consider for a moment that systems like QNX don't implement things like the page faulting half of virtual memory (though they still have separate address spaces) and ask yourself why they don't even in 1999 and you might begin to understand why there will never be an absolute guarantee on latency in Linux. Our average performance will be better though.
> > As for the parts of Linux, like the scheduling alogrithm, that appear to > > be optimized for multi-user time sharing systems, thats flat-out > > archaic, in my view. [...] > > a severe misconception again. The Linux scheduler is optimized for > latency, nothing else.
But the traditional time share algorithm (SCHED_OTHER) is in fact better for throughput (and fairness) than round-robin, et al. If you want SCHED_RR, it's there. I guess the proposal is that we "progress" to non-multi-user, non-time-sharing systems. Please point me to one of these more modern systems so I can avoid it.
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."
- 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/
| |