On Sun, 2003-08-31 at 21:51, Robert Love wrote: > On Sun, 2003-08-31 at 15:31, Ian Kumlien wrote: > > > Since they would have a high pri still, and preempt is there... it > > should be back on the cpu pretty quick. > > Ah, but no! You assume we do not have an expired list and round robin > scheduling. hummm, I assume that a high pri process can preempt a low pri process... The rest sounds sane to me =), Please tell me what i'm missing.. =) > Once a task exhausts its timeslice, it cannot run until all other tasks > exhaust their timeslice. If this were not the case, high priority tasks > could monopolize the system. All other? including sleeping?... How many tasks can be assumed to run on the cpu at a time?.... Should preempt send the new quantum value to all "low pri, high quantum" processes? Damn thats a tough cookie, i still think that the priority inversion is bad. Don't know enough about this to actually provide a solution... Any one else that has a view point? > > But, it also creates problems for when a interactive process becomes a > > cpu hog. Like this the detection should be faster, but should be slowed > > down somewhat. > > I agree, although I do think it responds fairly quick. But, regardless, > this is why I am interested in Nick's work. The interactivity estimator > can never be perfect. Hummm, the skips in xmms tells me that something is bad.. (esp since it works perfectly on the previus scheduler) > > But, hogs would instead cause a context switch hell and lessen the > > throughput on server loads... > > Hm, why? Since it's rescheduled after a short runtime or, might be. From someones mail i saw (afair), there was much more context switches in 2.6 than in 2.4. And each schedule consumes time and cycles. > > I don't see how priorities would be questioned... Since, all i say is > > that a task that gets preempted should have a guaranteed time on the cpu > > so that we don't waste cycles doing context switches all the time. > > But latency is important. Oh yes, but otoh, if you are really keen on the latency then you'll do realtime =) -- Ian Kumlien