RE: 2.6.4-mm1

["Nakajima, Jun" <jun.nakajima@intel.com>]

The part I like with this scheduler is that the common scheduler code
has no idea about the domains topology; it just traverses the pointers.
The domains are built in an architecture or platform specific fashion.
So that part can be a bit complex as observed, but that's a setup
business, not a runtime behavior. 

As we can have more complex architectures in the future, the scheduler
is flexible enough to represent various scheduling domains effectively,
and yet keeps the common scheduler code simple.

Jun
>-----Original Message-----
>From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
>owner@vger.kernel.org] On Behalf Of Nick Piggin
>Sent: Thursday, March 11, 2004 3:38 PM
>To: Andi Kleen
>Cc: Andrew Morton; linux-kernel@vger.kernel.org
>Subject: Re: 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/