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@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
