Bug#507248: realtime settings

Steve Langasek vorlon at debian.org
Sun Mar 8 22:22:23 UTC 2009


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.com                                     vorlon at debian.org





More information about the pkg-multimedia-maintainers mailing list