Bug#507248: realtime settings

[Adrian Knoth]

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.

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.

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


> Anyway, if there are per-user or per-group limits policies that packages
> need to apply, you can do that by adding your own conffile to
> the (non-existent by default) /etc/security/limits.d/ directory, as
> described in the pam_limits(8) manpage.

Ok, that's the way to go. jackd should provide it's own limit file.
Since jackd is the basic component in pro-audio, we just make sure these
users get all the power they want.


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

No. 


Cheerio

-- 
mail: adi at thur.de  	http://adi.thur.de	PGP/GPG: key via keyserver