> Since HMT is not an intel only problem it would be nice to solve this in
> a slightly more generic way than #if defined(__i386__) && defined(CONFIG_SMP).
> Otherwise there will shortly be yet another hack in the scheduler
> surrounded by #ifdef CONFIG_PPC64_HMT :)
Right but instead of saying "it doesnt work" it might be worth saying "it
doesnt work for me on ppc64". The latter I can well believe
> Its pretty obvious what they are trying to achieve (its always
> preferrable to schedule 2 tasks on separate physical cpus rather than
> sharing the same one), but their change does not seem to have the
> required outcome.
It's trying to ensure we make use of idle cpu units. Right now it doesn't
also consider the matching mm check to be per chip not per scheduling unit.
I've suggested that to Intel but not yet had any definitive answer stating
that it is an improvement.
[Actually it isnt always preferable there is a reverse argument in two
1. Where both threads share the same mm
2. When you are trying to save power over performance
> Do we have any results showing the improvement this change made or did
> we just accept the changes?
Its based on real world runs with things like Oracle with a constraint that
the change must be clear and provably correct to get into a stable kernel
tree. For 2.5 we know the scheduler has to be rewritten somewhat and getting
it generically right is very important.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Dec 15 2001 - 21:00:14 EST