Hallo, Ross Vandegrift hat gesagt: // Ross Vandegrift wrote: > On Sun, Feb 12, 2006 at 08:52:30PM -0500, Lee Revell wrote: > > No, it's not that bad, but IMHO it's more of a pain than the realtime > > LSM, or the PAM solution. > > Does a process inherit its parent's RT rlimits? I would expect them > to work that way. If so, it should be enough to run your display or > window manager under set_rlimits. Then, any app you started in that X > session would automatically inherit the ability to request RT > scheduling and mlock pages. > > Also removes the issue of overly fine-grained control. Anytime a user > with permission logged in, any app they ran will automatically work. > > Of course, if rlimits are process specific and not inherited, then its > moot. I thought about testing this last night, but went to sleep instead, > heh. set_rtlimits unfortunatly doesn't inherit, at least not in the way, you would prefer jackd to work. For example, to run jackd and ardour with higher priority, you need to start both jackd and ardour with "set_rtlimits -r" and the full path. I agree, that this is inconvenient and that set_rtlimits is to be considered just a temporary quickfix solution. However for example I had problems with realtime-lsm when suspending my laptop, so I had to configure unloading of the module and possibly reloading again after waking up. This is not necessary with set_rtlimits. When I find the time, I might play with PAM as well, however the latest patch I found didn't work with the latest libpammodules in Debian for me, and I was just too lazy to give it a deeper look, when set_rtlimits worked out of the box. I normally only run Pd anyways, and I only need Pd's realtime operation when performing, so this issue doesn't have a high priority (sic!) for me currently. Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__
