I don't know any formal schemes for doing priority allocation.
Given what I was saying before, I'd suggest something like this:
1. Sort the tasks according to latency required. You mentioned that a
few tasks are so critical that you cannot afford to let other tasks
run first. Quantitatively, that translates into a significantly
smaller latency requirement than the other tasks have.
Having done the sorting, partition the list into as few different
priority classes as you can. As I said, one is ideal; failing that,
try for two.
2. Determine the rate at which each task can be activated (worst case
and average). That may be an interrupt rate or a timer expiration
rate, depending on the task. Also determine how long it takes
(average and worst case) for each task to finish.
Use those numbers to verify that no tasks will be starved. For
example, if the sum across all the high priority tasks of the worst
case activation rate times the worst case completion time is greater
than 1, this means the high priority tasks can saturate your system.
If any of the low priority tasks are required for correct operation,
that would mean your system is broken.
Similarly, those calculations will let you determine the worst case
latency for tasks in each priority class. Given round robin
scheduling, a high priority tasks worst case has to wait for all tasks
of equal priority that were activated before it; worst case that's all
the other members of that priority class.
Simple example: if every task has equal priority, runs at 1 ms
intervals, and takes 100 microseconds to finish, if you have 11 of
them you're in trouble. And if you have 9 of them, the worst case
latency is 800 microseconds.
paul
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
