[LAU] The Many Ways of Pam Limits...

Looking at the various sources online giving advice about setting up realtime pre-emption in /etc/security/limits.conf, I found this mildly amusing list of recommendations from various sources. I've changed the group to 'realtime' in all cases just because that's what I use. # Gentoo: * hard rtprio 0 * soft rtprio 0 @realtime hard rtprio 20 @realtime soft rtprio 10 # Gentoo (Pro-Audio Overlay): @realtime - rtprio 90 @realtime - nice -5 @realtime - memlock 500000 # Arch: @realtime - rtprio 70 @realtime - nice -10 @realtime - memlock 250000 # Suse: @realtime - rtprio 100 @realtime - nice -10 @realtime - memlock 400000 # Debian: @realtime - rtprio 99 @realtime - nice -15 @realtime - memlock 250000 # Ubuntu: @realtime - memlock 0 @realtime - rtprio 99 # Jack: @realtime - rtprio 99 @realtime - memlock unlimited # Alsa: @realtime - rtprio 95 @realtime - memlock 512000 @realtime - nice -19 Hey, with concensus like this, how can you go wrong! :) These are the main questions this brought up for me: - Hard and soft limits: Most of these examples don't set separate hard and soft limits for anything, with the exception of the generic Gentoo realtime docs at the top. Since the soft limit is defined in the kernel.org documentation for pam_limits as "default values, for normal system usage", does this mean that if my account is in a group that sets a "soft" rtprio of 10 as shown in that example, that every process I launch gets that setting? A program with such permission still has to specifically request realtime, doesn't it, even with this "default" soft limit being present? It makes it kind of meaningless if your text editor, your desktop clock, and your file manager can all get that priority too automatically just because it's a "default", or so I'd guess anyway... - For most of the other examples, the '-' symbol is being used to set the hard and soft limits to be the same. Presumably this makes the "default for normal system usage" as sky-high as the maximum, as in the cases where a rtprio of 99 and unlimited memory locking is shown. This makes me think (hope?) even more that this is something an app needs to specifically request by asking the kernel for realtime, even under an account that has the PAM permissions! - Many sources actually say in their accompanying texts that allowing a negative niceness is not necessary, and thus do not. Others set a mild one ('-5' in the Gentoo Pro-Audio Overlay), and some like the Alsa Project documentation recommend scary-looking ones like '-19' that seem bound to get in the way of kernel services, if I'm not misinterpreting. How "not nice" should we allow a recording app to get? Or are the sources that don't set this on the right track? - Memlock is fairly self-explanatory to me. I'd presume you want to allow an app to memlock as much resident space as you expect your largest pro-audio app to take. I was wondering if there was anything to fear from non-pro-audio apps though in cases where the setting was "unlimited". This seems a possible loss of stability should one of your desktop programs go crazy for some reason...or is this, again, something that a program would have to request via a special call to the kernel, which wouldn't be likely from random errant behavior? What I'd really like to be able to do is run Qsampler/LinuxSampler with very large Gigasampler format libraries, and have it work well. I have 8GB of memory on my system, so should I memlock say 4-6GB or so? The common factor in all these questions is: Do these abilities have to be requested by a process through an extraordinary call the kernel, or does this open your whole desktop up to rampant memory usage, process priority elevation, etc. all the time? I'd mainly like only my pro-audio apps to make use of these abilities, even if I do grant them to my user account. -- + Brent A. Busby + "We've all heard that a million monkeys + UNIX Systems Admin + banging on a million typewriters will + University of Chicago + eventually reproduce the entire works of + Physical Sciences Div. + Shakespeare. Now, thanks to the Internet, + James Franck Institute + we know this is not true." -Robert Wilensky