8 Jan
2017
8 Jan
'17
8:25 p.m.
jackd on FreeBSD calls pthread_setschedparam(thread, SCHED_FIFO,
&rtparam) with rtparam.sched_priority = 10.
I am wondering where does 10 come from? The range for SCHED_FIFO is 0 ..
31, as returned by sched_get_priority_min() and
sched_get_priority_max(). The value 10 seems wrong, since the fastest
priority is 0, the slowest is 31.
In controlapi.c sched_get_priority_min()/sched_get_priority_max() are
called for OpenBSD. For this purpose FreeBSD should be the same. So it
should be #ifndef __OpenBSD__ && defined(__FreeBSD__).
Another problem is that FreeBSD doesn't allow to set thread priorities
for non-root users, but jackd is supposed to run by the regular user. At
least that's what libs expect it to be (/tmp/jack-{userid}). I have a
suggestion: if the process is run with realtime priority, jackd
shouldn't attempt to call pthread_setschedparam at all, because the
process realtime priority should be sufficient.
This code:
struct rtprio rtp;
res = rtprio(RTP_LOOKUP, getpid(), &rtp);
if (rtp.type != RTP_PRIO_REALTIME) {
// call pthread_setschedparam
}
allows to read priority of the process on FreeBSD.
The process can be run with realtime priority with this command: rtprio
0 jackd ...
Yuri
9 Jan
9 Jan
11:20 a.m.
On Sun, Jan 08, 2017 at 07:25:47PM -0800, Yuri wrote:
jackd on FreeBSD calls pthread_setschedparam(thread,
SCHED_FIFO, &rtparam)
with rtparam.sched_priority = 10.
I am wondering where does 10 come from? The range for SCHED_FIFO is 0 .. 31,
On Linux, it's 1 .. 99.
as returned by sched_get_priority_min() and
sched_get_priority_max(). The
value 10 seems wrong, since the fastest priority is 0, the slowest is 31.
On Linux, higher is definitely better:
"Processes with numerically higher priority values are scheduled
before processes with numerically lower priority values."
In controlapi.c
sched_get_priority_min()/sched_get_priority_max() are called
for OpenBSD. For this purpose FreeBSD should be the same. So it should be
#ifndef __OpenBSD__ && defined(__FreeBSD__).
Please send a patch or ideally a pull request on github. It's easier to
discuss.
Another problem is that FreeBSD doesn't allow to
set thread priorities
for non-root users, but jackd is supposed to run by the regular user.
You can always run without realtime priorities (-r or --no-realtime).
I'm surprised FreeBSD doesn't use PAM to allow users to call SCHED_FIFO.
You're sure about this?
HTH
--
mail: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver
12:54 p.m.
On 01/09/2017 10:20, Adrian Knoth wrote:
You can always run without realtime priorities (-r or
--no-realtime).
I'm surprised FreeBSD doesn't use PAM to allow users to call SCHED_FIFO.
You're sure about this?
It doesn't appear to be the case. PAM is user-level, and this checking
is kernel-level. I am not sure how this can be even done.
In any case, I submitted the pull request for using the process realtime
priority when available: https://github.com/jackaudio/jack1/pull/60
And my other statement about using sched_get_priority_max/min was wrong,
I misread the code, sorry.
However, it still isn't clear where does the value 10 come from.
Yuri
1:23 p.m.
On 01/09/2017 07:20 PM, Adrian Knoth wrote:
On Linux, it's 1 .. 99.
While we're at this, a quick heads up:
jackd can start various threads with given priority to 5 less than given
priority. If you use jackd -P 5 .. (or less) things may fail somewhere
down the road (jack process threads, watchdog,..).
Recent versions of qjackctl don't allow to configure priorities < 6
anymore. jackd itself won't complain or print a warning.
Another related issue: ffado requests a high priority. IIRC
jack's process priority + 5. There was a report on #lad the other day
where a user who was only allowed rt-prio 95, needed to start jackd -P
89. jackd -P90 failed.
ciao,
robin
10 Jan
10 Jan
2:07 a.m.
On Sun, Jan 08, 2017 at 07:25:47PM -0800, Yuri wrote:
Another problem is that FreeBSD doesn't allow to
set thread priorities
for non-root users
According to rtprio(1) manpage, users can set realtime priority if
sysctl variable security.bsd.unprivileged_idprio is set to non-zero.
I don't have a FreeBSD system to test this on, but it is of interest
to me. FreeBSD is looking increasingly attractive as Linux (which
I've used for pro audio work for 10+ years) acquires more and more
desktop-related baggage which requires increasing amounts of effort
to disable or remove.
John
2666
days inactive
2668
days old
jackaudio@lists.linuxaudio.org
5 comments
4 participants
participants (4)
-
Adrian Knoth -
John Rigg -
Robin Gareus -
Yuri