Messages in this thread | | | Date | Mon, 10 May 1999 06:16:40 +0200 (CEST) | From | Rik van Riel <> | Subject | Re: [patch] new scheduler |
| |
On Mon, 10 May 1999, Ingo Molnar wrote: > 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.
[snip]
> you dont seem to understand how the current scheduler works.
I do. I think you have overlooked the little defer trick that's present in wake_up_process()...
> 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.
No. Interactive processes that don't use up their time slice before jiffies reaches p->defer will get their time slice fully reinstated in wake_up_process().
> 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.
CPU hogs have their p->defer value always a few time slices in the future, while interactive tasks have their running deadline in the present. This means that interactive tasks are always preferred over CPU hogs. Multimeda apps will have their priority somewhere in the middle. Well, not really, but it will be like this on average...
> 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.
Problem is that this _only_ works if the interactive process doesn't use more than a few jiffies of it's time slice. I guess that rules out things like Enlightenment and Netscape from being considered interactive. _That_ is a bug, IMHO. My scheduler gives a little more leeway before a process is considered hogging the CPU.
I guess there will be no substitute for trying (which I will do as soon as I have backported the scheduler changes from the prepatch to 2.2.7 because the interrupt handling in 2.2.8 broke on my mainboard again).
cheers,
Rik -- Open Source: you deserve to be in control of your data. +-------------------------------------------------------------------+ | Le Reseau netwerksystemen BV: http://www.reseau.nl/ | | Linux Memory Management site: http://humbolt.geo.uu.nl/Linux-MM/ | | Nederlandse Linux documentatie: http://www.nl.linux.org/ | +-------------------------------------------------------------------+
- 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/
| |