Re: 2.6.4-mm1

[Nick Piggin]

Andi Kleen wrote:

> > > Some kind of SMT scheduler is definitely needed, we have a serious
> > > regression compared to 2.4 here right now. I'm not sure this 
> > > is the right approach though, it seems to be far too complex.

Andi, I'll agree that the way domains currently get set up is pretty
ugly. Maybe some additional functions or macros could be used to make
this process a bit clearer.

The actual kernel/sched.c code is really not that complex. In some ways
it is *less* complicated than the old numa scheduler because it all goes
through one code path.

It also handles SMT, which is where a bit of complexity is coming from.
The other alternative is shared runqueues which is uglier and less flexible.


> > Well that's discouraging.  I really do want to push this thing along a bit.
> >
> > Yours is the only report of regression of which I am aware.  Is the reason
> > understood?
>
> I think the reason is that it doesn't do balance on clone/fork. The 
> normal scheduler also doesn't do that, but for some reason it still does 
> better on the benchmarks (but worse than the old 2.4 -aa/Intel O(1) HT 
> scheduler)

There have been a few changes and bug fixes since you last tested.
Maybe that would help.

> > And is anyone developing alternative SMT enhancements?
>
> I thought there was a patch from Ingo Molnar? ("shared runqueue") 
> I must admit I never tried it, just remember seeing the patches.

Yep shared runqueues. Ingo and Rusty both had implementations but
they both agreed sched-domains was a better alternative.


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