Re: 2.6.8-rc2-mm2

Nick Piggin
2004-08-04T11:12:05Z

Con Kolivas wrote:
> Nick Piggin writes:

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

Oh ok. Well please don't remove the check anyway.

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

Well why would you want to disable it then?

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

No, I'm talking about one task getting *double* the amount of CPU as
another, when it should actually be getting a little bit less.

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

The mouse was often freezing for me when moving over windows with
IO running. That was an interactivity problem for me.

Thud itself isn't a problem I guess. Just thought you might like to know.

The test-starve problem actually is a problem though.

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

Well maybe it should be re designed. If an admin wants a task to get a
decent amount of CPU, it is not reasonable to nice +19 everything else.

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

No need to get a bee in your bonet. I was pointing out some things that
you need to fix if you are serious about this. I'd rather not replace
the scheduler with a known broken one.

Oh, and I would very much like you to criticise mine :)