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: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
