Messages in this thread | | | Date | Tue, 19 Aug 2003 15:34:06 +1000 | From | Nick Piggin <> | Subject | Re: [CFT][PATCH] new scheduler policy |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |