lkml.org 
[lkml]   [2004]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.4-mm1
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:01    [from the cache]
©2003-2011 Jasper Spaans