20 Jul
2004
20 Jul
'04
6:11 p.m.
On Tue, 2004-07-20 at 14:11, Ralf Beck wrote:
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
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.