Bug#507248: realtime settings

[Steve Langasek]

On Sat, Mar 07, 2009 at 10:53:26PM +0100, Adrian Knoth wrote:
> On Sat, Mar 07, 2009 at 01:14:26PM -0800, Steve Langasek wrote:

> > > First: I'm going to reassign this bug to libpam-modules, since
> > > /etc/security/limits.conf isn't owned by jackd.

> > > Second: There's usually no need to limit the size of the maximum locked
> > > memory. Actually, some programs (ardour?) even print a warning if you do
> > > so.

> > Then ardour should be fixed.  Why are *any* of these applications screwing
> > around with locked memory?  The purpose of locked memory is to have a secure
> > memory area that will never be written to disk in the swap space.  Sound
> > applications should *not* be second-guessing the kernel's memory management
> > by using mlock for performance reasons!

> Ardour is totally right here. It's a common way to ensure professional
> audio applications (like ardour) obey realtime limits. They have to
> read/write audio data within hard timing constraints, i.e. 5ms.

And it's common for Gentoo users to recompile their software with pointless
or incorrect optimization flags.  "Common" does not imply "correct".

You are second-guessing the kernel's memory manager when you do this.
Either the second-guessing has no effect, because the system has enough
memory that it's not an issue (which will be the case 99.99% of the time);
or you're applying arbitrary constraints on the kernel that will have an
indeterminate effect which may or may not result in the kernel meeting your
latency requirements.

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?

> 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.  But I don't see where that bug
lies; looking at the jack debian/rules, I see configure is passed the
'--disable-ensure-mlock' flag, which specifically means that it should not
fail to start if it can't lock the requested memory range.

> > You can't have more locked memory than you have physical
> > memory, so if one user can lock all the physical memory, then the other
> > users get none, even if there's additional virtual memory still available.

> We're talking pro-audio here, there are usually no other users.

Then don't ask me to set a system-level default for all Debian systems
that's only appropriate for single-user audio systems.

> > Removing the memlock limit is still wrong.  That needs to be fixed in
> > whatever app is abusing locked memory this way.

> No. 

Yes, it does, and I will file a critical bug report on jackd if I find it
removing the memlock limit on my systems.

-- 
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