[lkml]   [2004]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [announce] [patch] Voluntary Kernel Preemption Patch
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)


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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:04    [W:0.679 / U:5.524 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site