.......
Steve VanDevender wrote:
> This is where some people in this debate seem to have a gap in
> understanding. Linux, like the UNIX systems it's conceptually based on,
> is designed around timesharing, where any process that needs the CPU is
> going to get a fair share of CPU time averaged over a period of time,
> but isn't necessarily going to get the CPU immediately whenever it might
> want it.
> Even if you can reduce overall scheduling latency such that a
> process that needs fast scheduling response can get it on a
> lightly-loaded system, all you need to do is load up the machine until
> there are enough processes that want CPU, and fair timesharing
> scheduling will put a significant delay between all of their timeslices.
> The assumption that a process can and will have to wait arbitrary
> periods of time between its successive CPU timeslices is deeply
> ingrained in the OS, and there really isn't a mechanism for processes to
> signal to the scheduler that they must get the CPU NOW when specific
> events happen.
>
> Part of the assumption behind a realtime scheduler is that you are
> designing a system with a specific fixed set of processes that don't
> fight with each other and prevent the OS from satisfying their
> constraints. Realtime systems, even ones with only "soft" realtime
> constraints, aren't designed to cope with the idea of a user being able
> to start arbitrary processes at any time, and certainly can't promise
> that any arbitrary set of realtime constraints can be satisfied.
just to clarify: we are talking about SCHED_FIFO processes only:
there is no timeslice concept here
from the manpage:
----
SCHED_FIFO
is a simple scheduling algorithm without time slicing. For
processes scheduled under the SCHED_FIFO policy, the following
rules are applied: A SCHED_FIFO process that has
been preempted by another process of higher priority will
stay at the head of the list for its priority and will
resume execution as soon as all processes of higher priority
are blocked again. When a SCHED_FIFO process becomes
runnable, it will be inserted at the end of the list for
its priority.
----
So how does the SCHED_FIFO approach fit within multimedia applications
which are running simultaneously:
quite simple: assuming that the scheduler works reasonably ,
then just use higher SCHED_FIFO priorities (static) using the "earliest
deadline first" approach.
For example: a video player playing a video at 30FPS needs 30ms latencies,
an audio app with 5ms audio fragment size needs to be woken up every 5ms.
Simply run the audio app with higher SCHED_FIFO priority than the video app
(Beos does it in a similar way)
That means as soon an audio interrupt occurs , the audio app will be woken up
regardless if the video player was just rendering a frame.
At this point as soon as the audio app wrote the next fragment (which will
happen every 5ms), it will sleep, and control will go back to the video player.
In fact the video player will be interrrupted several times within the time it
takes to render a frame, but both will run perfectly happy as long as the total
CPU usage of the two apps will not exceed 100%.
If you invert the priority (video player higher than audio player), then
the video player will run ok, but the audio player will experience audio
dropouts.
Even when using RTLinux for these multimedia tasks, you have to meet
these priority conditions or it will simply not work, since you do not
reschedule during an RT task.
about: "ll you need to do is load up the machine until
there are enough processes that want CPU, and fair timesharing
cheduling will put a significant delay between all of their timeslices"
BTW: you can loadup ingo's kernel with 200 SCHED_OTHER threads
all burining up CPU, but the latencies doesn't increase,
since the SCHED_FIFO task is alway the first in the scheduler queue.
So Steve, before talking about "have a gap in understanding" , you
should do a more deeper research on this topic.
Benno.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:20 EST