[proaudio] pam-rlimits against rt-lsm kernel module

[Dominique Michel <dominique.michel@xxxxxxxxxxxx>]

It was a little discussion on that matter on the alsa user list, and it appear at it must be possible to archive exactly the same behaviour with pam-rlimits as with the rt-lsm. So, I must do more test in my box.

Here are the relevant points of this discussion if they can be useful to somebody.

Both are just ways to grant non root users SCHED_FIFO priorities for
their tasks.

Of course there are some subtle differences between rlimits and the
realtime lsm:

- rlimits allow specifying a maximum priority which uers processes are
allowed to aquire

- rt lsm otoh gives the user the ability to use any rt priority [or none
at all]

- rlimits allow specifying a maximum memory size for mlocking.

- rt lsm otoh again gives the user the ability to use any amount [or
none at all]

- rlimits allow specifying a maximum niceness which user processes are
allowes to aquire

- rt lsm otoh ... [well you get the picture]

The point being that rlimits allow for finer control of what a user
process is allowed to do. So depending on how you have rlimits
configured, you might get differing results from a rt lsm installation.

To my knowledge rt lsm and rlimits are just two different
ways to achieve the same thing: Giving user processes rt scheduling,
mlocking and negative niceness.

Let me add: If you actually have setup rt lsm and rlimits in an
equivalent way and  the rest of the system is the same, too, and you
still measure a difference, then you have found a bug in the kernel.
Please report it to lkml.

Florian Paul Schmidt

About watchdog and cpu throttling:

Ingo actually did an iplementation that
implemented cpu throttling. This was dropped though in favour of the
current rlimits implementation which does not do such a thing. The stand
of the linux kernel people was that cpu throttling (damage control for
runaway rt threads) can easily be implemented in userspace (i.e. by
leaving rt prio 99 to a watchdog process and setting rtprio to 98 in
limts.conf).

jack itself has a watchdog thread which kicks runaway processes
from the jack graph. The timeout of that is configurable. Maybe you use
different settings there and thus observe different kicking behaviour.
Plus this also depends on the box. So on two different computers you
might see differing behaviour even with the same programs and otherwise
identical setup.

Have fun,
Flo

P.S.: Don't take my word on any of this. Read the code, do the testing,
to be sure.

##############################

Dominique