[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
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user