>From your responses below, it is clear that you haven't noticed a
number of results I've published a few days ago.
> Richard believes that there is some source of variance in latency
> in scheduling that he cannot explain, that he claims is affecting
> the performance of an unspecified "real-time" application without
> explanation and without explaining the "real-time" requirements
> of that application, and is proposing to modify the scheduler
> based on these very vague observations.
Go read: http://www.atnf.csiro.au/~rgooch/benchmarks/ and you'll see
that I don't claim the RT performance is hurt by some unknown
variance. I make the point that RT performance is hurt by long run
queues. This is something that I've managed to pin down quite well,
despite spurious claims (without foundation) to the contrary.
> Larry's position is consistently that if the source of variance
> in scheduling cannot be explained (or even duplicated by other
> benchmarks), there is no reason to change the scheduler based
> purely on such vague observations. For some reason Richard is
> taking this way too personally.
I have shown that Larry is incorrect in this. I have used his
benchmark to demonstrate the effect of long run queues. I have also
used his benchmark to demonstrate variance.
You seem to have missed the results I published days ago.
> In any case, I think Richard's insistence that a timesharing
> system should also be good for real-time applications is
> untenable. A true real-time system has to provide guaranteed
> maximum response time to certain events and to some extent
> guaranteed throughput. This is inherently incompatible with a
> timesharing system that may encounter variable loads and resource
> demands; trying to run a real-time task on a system that is also
> being used as a timesharing system is foolish, as either the
> real-time task will suffer due to variation in load, or the
> real-time task's priority requirements will squeeze out the
> timesharing tasks. And traditional UNIXen are timesharing
> systems, not real-time systems. To me it seems perfectly
> sensible to have an separate RTLinux that is tuned for real-time
> rather than timesharing loads; most people really want
> timesharing systems (even if the application load is primarily
> interactive) because their performance degrades more reasonably
> under very high loads. A truly real-time system cannot cope with
> very high loads; ultimately CPU exhaustion puts a very hard limit
> on the number of simultaneous real-time tasks that can be run,
> and multiple real-time applications on the same machine are very
> likely to interfere with each other.
This isn't correct either. Again read my posts or my WWW page where I
describe a *real* normal user application which has good reasons to
cohabit with a RT application.
Furthermore, there are embedded applications which don't share with
normal users, and yet would derive benefit from a separate run queue
for RT processes. I'll be describing such a system in a subsequent
message.
Finally, I will again point out to all the naysayers out there, that
the change I propose:
- adds very little extra code
- simplies existing code paths
- improves RT performance under all conditions
- improves non-RT performance under all conditions
- properly isolates RT processes from normal processes in the
scheduler
- reduces the scope for bugs in the scheduler code.
Regards,
Richard....
-
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/