Bug#507248: realtime settings

On Sun, Mar 08, 2009 at 05:15:50PM +0100, Reinhard Tartler wrote:
>adi at drcomp.erfurt.thur.de (Adrian Knoth) writes:
> > On Sat, Mar 07, 2009 at 02:47:28PM -0800, Steve Langasek wrote:
> >> ardour uses mlock() on its ring buffers to ensure they're available in
> >> physical memory. What if in order to meet this requirement, the kernel
> >> instead swaps out the process stack and has to page that back in? What if
> >> it drops the pages for the program itself out of the disk cache, and has to
> >> read /that/ back from disk?
> > I won't discuss this. The kernel RT wiki is very clear on that point,
> > and all the audio developers do it for years.
> > http://rt.wiki.kernel.org/index.php/HOWTO:_Build_an_RT-application#Latencies_caused_by_Page-faults
> This article does not discuss Steve's arguments at all. While it is
> moderatly well written, I think that especially the part about page
> faulting needs more thought for general purpose systems like Debian.
Well, the article is right that using mlockall() will have the desired
effect wrt page faulting. It's just that:
- ardour, the example given, doesn't *use* mlockall(), and using just
mlock() doesn't give you any latency benefits at all.
- if you really have a 970MB sample file that you need locked in memory,
that plus the program plus stack+heap means you need > 1GB physical memory
just to run this one application. I suppose these days it's
straightforward to get a machine with 4GB of RAM or more, but for most
people a memory requirement like this still means you're going to run the
app on dedicated hardware; so if there's no resource contention, then
mlockall() is redundant. (but permitting mlockall to work is simpler than
uninstalling all the other packages that /could/ cause contention, via
cronjobs etc.)
> >>> > Increasming the mlock limit is a must and number one recommendation all
> >> > over the net for pro-audio. jackd won't even start with realtime
> >> > priority with the kernel's 32k limit.
> >> Then that's a bug in the jackd package.
> > Ok, it starts, but it won't have RT prio. And without RT prio, it's
> > mostly pointless (especially in case of firewire audio interfaces
> > handled by FFADO, resulting in many underruns and therefore crackle)
> Perhaps we can do something with filesystem capabilities? Or perhaps
> even some suid wrapper that drops priviledges immediatly after setting
> the right priority? I cannot imagine that this hasn't been discussed yet
> upstream. Could you (or anyone) provide pointers here?
At least wrt setting the rtprio, I'm much more comfortable with having a
config file added to /etc/security/limits.d than seeing more suid root
wrappers added to the system. That doesn't solve the mlockall() question,
though; but any solution that lets the audio user lock all the physical RAM
is going to be a problem for the general case.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/slangasek at ubuntu.comvorlon at debian.org