Re: [CFT][PATCH] new scheduler policy

[Nick Piggin]

Matt Mackall wrote:

> 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.

Hmm... did I do that? I don't actually have the code in front of me, but I
think the timeslice split is still 50/50 (see fork.c). Its the priority
points that go 2/3 to 1/3. Actually its a bit more complex than that even
and probably not exactly right...


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/