Re: 2.6.8-rc2-mm2

[Nick Piggin]

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 :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/