Re: [announce] [patch] Voluntary Kernel Preemption Patch

[Benno Senoner <sbenno@gardena.net>]

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).

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.
Perhaps in upcoming Linux kernel/driver programming books this issue 
should be stressed out and
mentioned prominently in order to avoid the eternal:
fixing latencies in kernel x.y.z -> new kernel versions with new 
drivers/changes/enhancements comes out
-> latencies are bad again -> fix latencies in this new kernel version  
.....  ( iterate at infinitum)

cheers,
Benno
http://www.linuxsampler.org


Lee Revell wrote:

>On Tue, 2004-07-20 at 14:11, Ralf Beck wrote:
>  
>
>>>it's an issue for all block IO drivers that do IO completions from IRQ
>>>context and that can do DMA - i.e. every block IO hardware that uses
>>>interrupts. This includes SCSI too. In fact for SCSI it's a norm to have
>>>      
>>>
>>I renew a question i asked earlier.
>>
>>To my understanding, on a SMP or hyperthreading system, disabling of
>>IRQs is always local to one (virtual on HT) cpu.
>>
>>So would it be possible to get ultralow latency by simply hardlock all irqs 
>>and processes to cpu1 and the irq triggering the audiothread (together with 
>>the audiothread) to cpu 2 using the sched_affinity and irq-affinity 
>>capabilites of the kernel?
>>
>>This would be an easy to use lowlatency hardware patch for  linux audio users
>>with SMP/HT systems. Anybody knows?
>>
>>I'm currently thinking about getting a new system and consider a dualsystem if 
>>this worked.
>>    
>>
>
>Should work.  For example, the RTLinux people report excellent results
>on SMP systems by binding all RT threads to one CPU and having the Linux
>part of the system run on the other.  This is just a "softer" version of
>that setup.  Even if there are cases where IRQs are disabled globally,
>it would be an improvement.  I suspect you are not getting much of a
>response because no one has actually tested it with an audio system.
>
>Lee
>
>
>  
>