Re: [linux-audio-dev] set_rtlimit problem

From: Lee Revell <rlrevell@email-addr-hidden-job.com>
Date: Mon Nov 28 2005 - 02:10:43 EET

On Mon, 2005-11-28 at 10:27 +1030, Jonathan Woithe wrote:
> Hi 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.

Sorry, I should have been clearer. set_rtlimits (and JACK) are doing
the right thing, I consider this a kernel bug.

Lee
Received on Mon Nov 28 04:15:10 2005

This archive was generated by hypermail 2.1.8 : Mon Nov 28 2005 - 04:15:10 EET