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

[Paul Davis]

On Sun, Jul 19, 2009 at 11:17 PM, michael noble<looplog at gmail.com> wrote:
>
> On Mon, Jul 20, 2009 at 7:15 AM, Paul Davis <paul at linuxaudiosystems.com>
> wrote:
>>
>> 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.
>>
>
> Can you expand on this a little? Are you saying there is absolutely no need
> to include a nice setting in limits.conf? Is this just some wacky tradition
> that has been handed on between linux audio distros and metadistros? Don't
> get me wrong, you probably know better than I, but it'd sure be nice to hear
> an informed reason to abandon this practice.

there are a few applications out there that seem to believe that you
can improve audio performance (i.e. less dropouts under load) by
changing their own nice value. this represents a complete
misunderstanding of the differences between conventional Unix
scheduling ("SCHED_OTHER") and realtime scheduling like SCHED_FIFO and
SCHED_RR. using nice can, under a few circumstances, make a
difference, but its use basically means that the developer(s) really
don't understand what the issues are.

presumably some distros believe that their version of limits.conf
should accomadate this kind of misconception. i don't think that
limits.conf should be specifying a nice value, at least not in
connection with audio/music applications that inherently need realtime
scheduling.