Re: 2.6.8-rc2-mm2

Con Kolivas
2004-08-04T10:12:37Z

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