Subject: Re: [linux-audio-dev] SCHED_FIFO versus SCHED_RR
From: Paul Davis (pbd_AT_Op.Net)
Date: Mon Nov 26 2001 - 23:01:12 EET
>Q: Do the SCHED_FIFO bugs prevent a simple use of sched_setscheduler() to
>bump the priority of a thread that is reading and writing to OSS? I want the
>code to work on old systems as well as new.
No. The bug(s) you have heard about did not affect the use of
SCHED_FIFO. It affected the way the kernel scheduled kernel threads in
this scheduling class. It meant that what a thread expected from using
SCHED_FIFO wasn't being honored by the kernel.
>Q: Does SCHED_RR work better than SCHED_FIFO? Fewer bugs?
No. It doesn't work better or worse. The situation is more complex
than that. SCHED_RR is designed for situations where there are several
"real time" kernel threads and you wish to ensure that they all get
time on the processor, regardless of their own intentions. the RR
stands for "round robin". SCHED_FIFO is different in that once a
thread is running, it will run forever, or until it yields, blocks or
a higher priority SCHED_FIFO thread is runnable. its designed for
situations where there is either only 1 "real time" kernel thread, or
a set that are intended to do cooperative multitasking.
>Q: I have code that throttles back if I consume too much CPU time. Is that
>sufficient?
sufficient for what?
>Q: Can I safely use the value from sched_get_priority_max(SCHED_FIFO) or
>should I use less?
its up to you. if you use the max value, its impossible for anyone to
ever kill you if your thread gets stuck in a loop. OTOH, since there
are no standard systems to kill you if your thread gets stuck in a
loop, thats somewhat besides the point right now.
--p
This archive was generated by hypermail 2b28 : Mon Nov 26 2001 - 23:00:11 EET