Re: [CFT][PATCH] new scheduler policy

Matt Mackall
2003-08-19T05:17:43Z

On Tue, Aug 19, 2003 at 12:59:57PM +1000, Nick Piggin wrote:
>
>
> Nick Piggin wrote:
>
> >
> >
> >William Lee Irwin III wrote:
> >
> >>On Tue, Aug 19, 2003 at 11:53:01AM +1000, Nick Piggin wrote:
> >>
> >>>As per the latest trend these days, I've done some tinkering with
> >>>the cpu scheduler. I have gone in the opposite direction of most
> >>>of the recent stuff and come out with something that can be nearly
> >>>as good interactivity wise (for me).
> >>>I haven't run many tests on it - my mind blanked when I tried to
> >>>remember the scores of scheduler "exploits" thrown around. So if
> >>>anyone would like to suggest some, or better still, run some,
> >>>please do so. And be nice, this isn't my type of scheduler :P
> >>>It still does have a few things that need fixing but I thought
> >>>I'd get my first hack a bit of exercise.
> >>>Its against 2.6.0-test3-mm1
> >>>
> >>
> >>Say, any chance you could spray out a brief explanation of your new
> >>heuristics?
> >>
> >
> >Oh alright. BTW, this one's not for your big boxes yet! It does funny
> >things with timeslices. But they will be (pending free time) made much
> >more dynamic, so it should _hopefully_ context switch even less than
> >the normal scheduler in a compute intensive load.
> >
> >OK. timeslices: they are now dynamic. Full priority tasks will get
> >100ms, minimum priority tasks 10ms (this is what needs fixing, but
> >should be OK to test "interactiveness")
> >
> >interactivity estimator is gone: grep -i interactiv sched.c | wc -l
> >gives 0.
> >
> >priorities are much the same, although processes are supposed to be
> >able to change priority much more quickly.
> >
> >backboost is back. that is what (hopefully) prevents X from starving
> >due to the quickly changing priorities thing.
>
> And lack of interactivity estimator.

You forgot to mention fork() splitting its timeslice 2/3 to 1/3 parent
to child.

--
Matt Mackall : http://www.selenic.com : of or relating to the moon