Please get your definitions straight before continuing this discussion.
"Real time" scheduling is defined in relation to deadlines, and is
done such that no tasks miss any deadlines (when possible). If it's
occasionally permissible to miss a deadline or two, you have "soft"
realtime. If no deadline may ever be missed (by a correctly functioning
system), you have "hard" realtime.
Note how task period, latency, and shortness of time to deadline *don't*
figure in the above definitions.
Now, if you have a real time task which must be schedulable but has
less slack than the expected worst case latency, either live with
the possibility of missing a deadline or two, optimize the task,
or describe this particular task and why it can't be redesigned
*and* must run under the mainstream Linux kernel, not RT-Linux...
...and in any case, please stop conflating "real time" with "fast
response and low latency".
> OK, you tell me what's better:
> 1) a simple system with a fair worst-case latency for RT tasks
> 2) a slightly more complex system with excellent worst-case
> latency for RT tasks and a slightly worst latency for non-RT
> tasks
A few microseconds making "fair" become "excellent" in the worst
case? It seems like your "worst case" scenario is neglecting
interrupts completely (besides the one that triggers your
hypothetical short-deadline low-slack task)...
Keith
-- "The avalanche has already started; |Linux: http://www.linuxhq.com |"Zooty, it is too late for the pebbles to |KDE: http://www.kde.org | zoot vote." Kosh, "Believers", Babylon 5 |Keith: kwrohrer@enteract.com | zoot!" www.midwinter.com/lurk/lurker.html |http://www.enteract.com/~kwrohrer | --Rebo- 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/