On Sun, Jul 19, 2009 at 12:18 PM, Brent Busby<brent@xxxxxxxxxxxxx> 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. _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
