Oh please. Having read quite a bit of this debate, I'm much more
supportive of Larry's point of view than Richard's.
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.
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.
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.
-
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/