27 Nov
2005
27 Nov
'05
7:10 p.m.
On Mon, 2005-11-28 at 10:27 +1030, Jonathan Woithe wrote:
Hi Lee
Sorry, I should have been clearer. set_rtlimits (and JACK) are doing
the right thing, I consider this a kernel bug.
Lee
I just noticed that the sys_get_priority_max and
_min syscalls do not
take the RT priority rlimit into account. Since the watchdog thread
runs at the -P setting + 10 then if the rlimit is 50 and the user
specifies -P50 the watchdog thread will fail.
I believe sched_get_priority_max(SCHED_FIFO) needs to take the rlimit
into account - there's no other way to get the upper limit AFAICT.
I'm not sure what the "set_rtlimit problem" is here - I'm a little
confused.
In terms of what set_rtlimits does, it seems to me that the watchdog thread
issue can be easily dealt with: define the max rtpriority value in
/etc/set_rtlimits to be X, knowing that the maximum jackd "-P" option value
one can use is X-10.
Certainly getrlimit()/setrlimit() (which set_rtlimit uses to do its thing)
seem to take the current rtpriority rlimit into account. The former
also returns the rlimit hard limit for the process, which I interpret
to be the "upper limit" mentioned in the original email.
In testing I've done during development, set_rtlimits seems to do the right
thing, based on my understanding of what the right thing is. If I've
misunderstood something though I'm happy to be corrected.