Re: 2.6.4-mm1

[Nick Piggin <piggin@cyberone.com.au>]

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.