Re: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch

[Lee Revell <rlrevell@joe-job.com>]

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