Re: [CFT][PATCH] new scheduler policy

[Nick Piggin <piggin@cyberone.com.au>]

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