Re: 2.6.8-rc2-mm2

[Con Kolivas <kernel@kolivas.org>]

Nick Piggin writes:

> Con Kolivas wrote:
>> Con Kolivas writes:
>> 
>>> Nick Piggin writes:
>>>
>>>> Con Kolivas wrote:
>>>>
>>>>> Andrew Morton wrote:
>>>>
>>>>
>>>>> Anyone with feedback on this please cc me. This was developed 
>>>>> separately from the -mm series which has heaps of other scheduler 
>>>>> patches which were not trivial to merge with so there may be 
>>>>> teething problems. Good reports dont hurt either ;)
>>>>>
>>>>
>>>> I can't get onto the OSDL site now, but I seem to remember staircase
>>>> having some performance problems on a few things. Hackbench and reaim
>>>> from memory... are these fixed? was I dreaming?
>>>
>>>
>>> Definitely dreaming I'm afraid :D
>>>
>>> The performance on both reaim and hackbench has always equalled or 
>>> exceeded mainline so thanks for bringing it up.
> 
> (OSDL's search thingy still isn't working quite right, but I'll get back
> to you about this when it does.)
> 
> 
> Otherwise, a couple of problems I noticed:
> 
> You removed things like this:
> -	/*
> -	 * The idle thread is not allowed to schedule!
> -	 * Remove this check after it has been exercised a bit.
> -	 */
> -	if (unlikely(current == rq->idle) && current->state != TASK_RUNNING) {
> -		printk(KERN_ERR "bad: scheduling from the idle thread!\n");
> -		dump_stack();
> -	}
> -
> And child-runs-first in wake_up_new_task. Please don't.

It does child runs first by design in staircase. You don't need any more.

> Also, basic interactivity in X is bad with the interactive sysctl set to 0

Well duh... disable interactivity and interactivity is bad. What's the 
problem? It's not meant to be used on a desktop in that way. 

> (is X supposed to be at nice 0?), however fairness is bad when interactive is 1.
> I'm not sure if this is an acceptable tradeoff - are you planning to fix it?

Why? A single user desktop is hardly needing extremely accurate cpu 
distribution... we see that already in 2.6. 

> It has interactivity problems with "thud". Also the mouse can freeze for .5 to 1
> second when moving between windows while there is disk IO going on in the background
> (this is with interactive = 1). The test-starve problem is back.

Hmm? a minor mouse freeze with a _test_ starvation program is not 
starvation; nor is it an interactivity problem. Yours is the first complaint 
about interactivity during i/o.

> Increasing priority (negative nice) doesn't have much impact. -20 CPU hog only gets
> about double the CPU of a 0 priority CPU hog and only about 120% the CPU time of a
> nice -10 hog.

-20 is 40 rr intervals. 0 is 20 rr intervals. +19 is 1 rr interval. 
Seems to me the cpu distribution is working our absolutely perfectly as 
designed.

Why is the only critic of this the person with a competing design? Does 
anyone else object to these things? I certainly dont feel objective enough 
to criticise yours.

Con