19 Jul
2009
19 Jul
'09
8:15 p.m.
On Sun, Jul 19, 2009 at 12:18 PM, Brent Busby<brent(a)keycorner.org> wrote:
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.
The nice value is irrelevant. Anybody attempting to use nice(2) to
improve realtime performance doesn't understand what they are doing.
It is very unfortunate that this has crept into so many limits.conf
examples.
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!
an app does not get RT scheduling without asking for it or being
granted it by another app that asks for it as a proxy.
no app uses memory locking without explicitly asking for it itself.
- 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".
"unlimited" is an easy answer. a better value would be something like
80% of physical RAM. unfortunately, PAM appears to have no way of
handling (or even parsing) such a specification, so the user or some
install script would have to determine it, and if they ever install or
remove RAM it would need manually fixing.
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.
apps that do not current ask for SCHED_FIFO/SCHED_RR and/or do not ask
for memlock will not start using these facilities just because you've
made it possible for any process running as you to do so.