Messages in this thread | | | Subject | Re: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch | From | Lee Revell <> | Date | Tue, 20 Jul 2004 20:32:37 -0400 |
| |
On Tue, 2004-07-20 at 19:49, Benno Senoner wrote: > While locking a RT process to a CPU to achieve even lower latencies > might be useful to some > the general userbase wants good latencies on simple UP, non HT-enabled > hardware too. > (AMD is gaining marketshare and we cannot simply expect that good > multimedia performance (aka low latency) > can be achieved only on those SMP/HT boxes where the truth is that > except in the case of really crappy hardware, > those common UP machines are actually capable to delives latencies in > the range of dozen of usecs. > (taking the RTLinux benchmarks as reference). > Of course Linux != RTLinux and we never expect nor pretend Linux to > match the response time of RTLinux but > as said earlier latencies at around 1msec should are doable on decent UP > boxes and this is more than > adequate to run demanding real time audio applications like software > synthesizers, samples, real time effects etc. > The only hope is that the hard work from Ingo, Andrew and all the others > gets soon integrated in the mainstream > 2.6 kernel so all Linux users can take run demanding multimedia > applications out of the box without going through > the painful patching,kernel recompiling etc. > Or is this still not realistic at this point ? > (see the old issue with kernel 2.4, low latency patches were too > unclean to make it into the > ufficial kernel tree). >
There are still a few areas that need work, ioctl gives me problems, but the latest 2.6 kernels are quite good. If you look at the 'clean' version of the voluntary kernel preemption patch it is pretty small. My understanding is that the kernel is already preemptible anytime that a spin lock (including the BKL) is not held, and that the voluntary kernel preemption patch adds some scheduling points in places where it is safe to sleep, but preemption is disabled because we are holding the BKL, and that the number of these should approach zero as the kernel is improved anyway.
> Plus what's very important is that every kernel developer and driver > developer (even thirdparty, especially those > that do closed source stuff like Nvidia etc) takes into account the > latency problems that code paths that run for > too long time (or disable IRQs for too long etc) might create. > While I'm not a kernel expert I assume the premptible kernel alleviates > this problem but I guess it still cannot > completely get rid of low latency-unfriendly routines and drivers.
Yes, this is important. One problem I had recently with the Via EPIA board was that unless 2D acceleration was disabled by setting 'Option "NoAccel"' in /etc/X11/XF86Config-4, overloading the X server would cause interrupts from the soundcard to be completely disabled for tens of milliseconds. Users should keep in mind that by using 2D or 3D hardware acceleration in X, you are allowing the X server to directly access hardware, which can have very bad results if the driver is buggy. I am not sure the kernel can do anything about this.
Lee
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |