Thank you very much for the lecture, I'd want more
and more :-)
I am pleased you enjoyed it. Most people find my diatribes rather dry reading.
I'm happy to see, almost all of the mentioned
(except for bdflush)
settings are more or less optimum.
Excellent.
I have another idea too. Since in a DAW scenario, it's STUPID to
write-buffer really [you're spooling out lots of data which you're not going
to need again anytime soon], I'd inspect the source to see if they open the
file in O_DIRECT mode. This removes the buffer cache entirely from the
equation and does not induce memory pressures upon the kernel.
All "large spooling" I/Os (read or writes) should use O_DIRECT for realtime
operations where the likelihood of re-reading the file is zero. When you're
EDITING the file, fine. But when you're capturing, I suspect you will see
more wins if you're using O_DIRECT. You can get big wins if you use
O_DIRECT and use multiples of the physical memory pagesize. (Zero-copy write
path - super-dee-duper efficient!)
With O_DIRECT you will eliminate the CPU waste (and locking!!) of wasteful
double-buffering, and reduce memory copying. If you set up the I/Os
properly, you will in fact have a direct-to-disk DMA channel from the audio
buffer. This is Perfection.
Let me recall my question: I think, there are more
than one (lck1)
possible kernel patches with the aim of solving lowlat/preempt/...
issues. Which of them is the most appropriate for using with jack?
All of them, though strictly speaking, the 64-bit jiffies patch does not
boost performance.
I still use 2.4.26.
Sounds fine.
I'm assuming you're using the patches at:
<http://www.plumlocosoft.com/kernel/> (Con Kolivas's patches now maintained
by E Hustvedt).
Apply all of the patches, and enable lowlatency. I use all of them except
for 012-rl2dt.diff.bz2 on my main servers [non-audio/realtime oriented] to
excellent effect.
If you're really hardcore, you can live without 64-bit jiffies, however when
HZ=1000 you'll wrap your jiffy counter in under 40 days.
I think HZ=1000 will get you some gains in responsiveness for applications
which do ANY select() multiplexing. Ignore the rants about "wastes due to
more interrupts" - that's under 1% on modern CPUs. The AXP (Alpha) platform
has been using HZ=1000 for years, and even a $50 Athlon XP 2000 leaves that
for dead. On pre-Pentia CPUs, there's a reasonable argument to be made for
HZ=100.
Lord Sauron could have won, if only he had Quality,
=MB=
--
A focus on Quality.