Messages in this thread | | | Date | Tue, 02 Sep 2003 10:04:27 +1000 | From | Nick Piggin <> | Subject | Re: [SHED] Questions. |
| |
Ian Kumlien wrote:
>[Forgot CC to LKML and Robert Love, sorry ] > >On Mon, 2003-09-01 at 17:07, Daniel Phillips wrote: > >>On Monday 01 September 2003 01:41, Robert Love wrote: >> >>>Priority inversion is bad, but the priority inversion in this case is >>>intended. Higher priority tasks cannot starve lower ones. It is a >>>classic Unix philosophy that 'all tasks make some forward progress' >>> >>So if I have 1000 low priority tasks and one high priority task, all CPU >>bound, the high priority task gets 0.1% CPU. This is not the desirable or >>expected behaviour. >>
In my implementation, the high prio guy gets 1.9% CPU and the others get 0.09%. However, in all implementations, the high priority one will be allowed to preempt the any of others, of course.
At this point you can safely abandon the consideration that a user might be running KDE as well ;)
> >>My conclusion is, the strategy of expiring the whole active array before any >>expired tasks are allowed to run again is incorrect. Instead, each active >>list should be refreshed from the expired list individually. This does not >>affect the desirable O(1) scheduling property. To prevent low priority >>starvation, the high-to-low scan should be elaborated to skip some runnable, >>high priority tasks occasionally in a *controlled* way. >> > >I like this idea. >You could handle the priority starvation with a "old process" boost. >(i don't know which would be simpler or if there is something even >simpler out there) > >This would ensure that all processes are run sooner or later. Real >cpuhogs would run very seldom due to being starved, but run when they >get the boost. On a loaded system this might be desirable since most >login tools would be "normal" or "high pri" from the get go. >(there might be a problem with locks though) > >This should also work hand in hand with timeslice changes imho. Aswell >as process preemption. If we assume that cpu hogs has work that they >want to get done, let em do it for as long as possible. If something >"important" happens, it'll be preempted right? >
This is really just another variation on the idea of dynamic timeslices. Mine does it explicitly. This idea and the interactivity idea do it implicitly (not that thats bad).
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |