Subject: Re: [linux-audio-dev] Help on threads needed
From: Paul Davis (paul_AT_linuxaudiosystems.com)
Date: Mon Nov 04 2002 - 18:29:07 EET
>I'm just trying to tweak SpiralSynthModular's threads to be a bit more
>efficient, and I can't seem to find much info regarding thread priorities and
>such.
>
>I have two threads, a GUI one and an audio one. I can hand the audio thread
>over to Jack which works fine, but I'd also like to be able to run ssm in
>normal user mode and standalone without jack. I think I have two questions:
>
>1. Is there any way to prioritise the threads running as a normal user
>(SHED_OTHER) my man pages suggest not, which is quite annoying. Should I
>"nice" the GUI thread down in priority?
in the SCHED_OTHER class, its not possible to override the "fair
scheduling" characteristics of the kernel scheduler. you can certainly
use nice to adjust the relative priorities of the threads (well,
actually, sched_setparam()) and this will alter the way the threads
are scheduled. but the scheduler takes elapsed cycles into account,
and sooner or later may choose to run a thread will lower priority
than another runnable thread just because the latter one has been
hogging CPU cycles. there is no way around this theoretical
possibility, because its an intentional design. its also why SCHED_RR
and SCHED_FIFO exist, because these scheduling classes are not covered
by that rule. if a SCHED_FIFO thread can run, and there are no
SCHED_FIFO threads ready to run with higher priority, then that thread
runs, regardless of whether it uses 99% or 1% of available CPU time.
try "man sched_setscheduler" for a decent overview of this.
>2. What is the correct setup for SHED_FIFO? What priorities should I run the
>audio and GUI threads at, and should the GUI thread use SHED_FIFO too?
the audio thread should run at (at most) (sched_get_priority_max() -
1) to allow for any watchdog system to run. it may be wise to add a
watchdog thread that runs at sched_get_priority_max() and wakes up
every 5 seconds or so to check that progress is still being made. JACK
includes such a thread, for example. this prevents endless loops in a
SCHED_FIFO code from taking complete control of a single CPU
system. it would be nice if there was a way to do this outside the
application (i.e. a system wide check), but i don't see anyway to do
this.
IMHO, the GUI thread should not run SCHED_FIFO - nothing is really
served by this. if anything was going to run SCHED_FIFO in the GUI, it
would be the X server, but this won't accomplish much under most
circumstances. if you did use SCHED_FIFO for a GUI thread, it should
be at a lower priority than the audio thread. otherwise, the
SCHED_FIFO/SCHED_OTHER difference will ensure correct "prioritization"
of the threads.
--p
This archive was generated by hypermail 2b28 : Mon Nov 04 2002 - 18:37:42 EET