Messages in this thread | | | Subject | Re: a joint letter on low latency and Linux | Date | Sun, 02 Jul 2000 20:23:25 -0400 | From | Paul Barton-Davis <> |
| |
>> although this certainly appears to be the case in general, it hasn't >> been true of latency. Not only is 2.4.0-anything worse than 2.2, but >> Linux is probably the slowest of any OS that anyone I know has >> looked into when it comes to return-from-interrupt-driven >> scheduling. it could be that this is because nobody has bothered to >> pay much attention to this issue. if so, i just hope that these >> exchanges will do something to change that. > >Really? It's been a while since I've done any measurements, but IIRC, >I was getting IRQ latencies of about 20 us on a 386 back in September >1998. Sure, sometimes it would be much worse (other drivers blocking >IRQs), but it indicated the basic code path was short. > >Context switches were < 25 us.
neither of these numbers are germane. the problem is not how rapidly an interrupt handler runs (though this is important). what matters in this context is how fast a thread thats been marked runnable (and whose scheduling class and priority require that it be given the processor ASAP) has to wait after the end of the interrupt before it is running again.
>> historically, they *have* been ignored, at least as a practical >> matter. i doubt that anyone was trying to ignore them, but the result >> has been incredibly long delays in scheduling under many common >> situations. we're not talking about mindcraft/finessable differences >> here, but factors of 5-100. > >Do you have numbers showing that things have gotten much worse as time >has progressed? And by how much? If so, it's worth looking into.
I don't know whether they have gotten worse or better. It wouldn't suprise me if they've never been that good. Linus says that latency has always been a concern of his, and its possible that for the main kernel code, this is reflected, but that various device drivers and changes to them over time don't show the same care. Its also possible (i might even guess likely) that most kernel developers rarely if ever run applications that require this kind of behaviour, and so the kernel has possibly never had much better performance than it does now.
Benno has done measurements on the 2.2->2.4 transition, but as he has commented, the situation with the VM system makes it unwise to read too much into the numbers at this time.
The "factors" mentioned above are based on the results of people on non-Linux audio mailing lists who work like mad to get the best results from Windows and MacOS, as well as other sources for other OS's. Solaris is the only one I am not really sure about relative to Linux, but some people have told me that its much better.
--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/
| |