Messages in this thread | | | Date | Mon, 10 May 1999 01:13:41 +0200 (CEST) | From | Ingo Molnar <> | Subject | Re: [patch] new scheduler |
| |
On Mon, 10 May 1999, Rik van Riel wrote:
> > you have removed priority recalculation, but priority recalculation has a > > goal: not running processes gather priority approaching maximum priority > > (40) logarithmically. This is how we 'boost' interactive processes > > automatically. Maybe i've misread your patch, but where is this mechanizm > > now? (or if it's replaced by something else, how does that work?) > > The mechanism is in the handling of the p->defer value. > > If the proces runs out of it's time slice, it gets > put away in time according to it's priority. If it > sleeps and returns after p->defer has happened, it > will get full priority and p->counter will be set > to full. > > Handling of interactive and multimedia tasks will > be done because CPU hogs are pushed back in time > and interactive and multimedia tasks aren't put > back as much.
you dont seem to understand how the current scheduler works. Tasks are started with 'normal' priorities. Things like 'telnet' or other interactive processes tend to spend only a fraction of their 'due' CPU time. Subsequently they get a priority boost to _well above their original priority_.
If i understand your changed timeslice mechanizm correctly then 'interactive' processes would have typically 'normal' priority, which is then slightly decreasing until it reaches zero. (which btw. might be just a bug in your scheduler) But anyway, the more important point is that the mechanizm of _boosting_ interactive processes above the priority of CPU-hogs does not seem to be present. No, CPU-hogs are not necesserily reniced processes ... All in one, you end up having a much worse scheduler.
as i said earlier, solely concentrating on removing the recalculation factor is i think misguided effort, the logarithmic priority boost resulting out of recalculation is a _feature_, implementing it in another way (ie. with getting the same benefits) might be possible, but removing it without having a substitute is plain wrong.
just to give you an example, with the current 2.2.8 scheduler, run 4 CPU-hogs and use some interactive process. The interactive process _always_ preempts the CPU hog (after some initial 'learning curve'), even if the CPU hog has slightly higher priority than the interactive process. This happens the very same way on SMP as well, eg. take 3 RT tasks on a 4-CPU box and 2 'normal' CPU hogs, interactive processes will _always_ preempt the CPU hogs on whatever CPU they run. It cannot get any better as far as interactivity goes, can it?
-- mingo
- 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/
| |