Messages in this thread | | | From | Steve VanDevender <> | Date | Mon, 28 Sep 1998 16:24:57 -0700 (PDT) | Subject | Re: [PATCH] scheduler patch, faster still |
| |
Kurt Garloff writes: > On Mon, Sep 28, 1998 at 01:32:42AM -0600, Larry McVoy wrote: > > ... > > Sorry, Larry, I think you know very well what you are talking about, but > your style of saying it gives everybody the impression that you are in love > with the current scheduler code and everybody who suggest changes is hurting > your feelings. So your answers are really not very nice to read.
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/
| |