lkml.org 
[lkml]   [2004]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Load balancing problem in 2.6.2-mm1


Rick Lindsley wrote:

> Yep. I've argued for fairness here, and that is presently what
> we get. Between nodes the threshold should probably be higher
> though.
>
>While I like the idea of a self-tuning scheduler, when combined with
>this new sched_domain algorithm it's hard to tell if the tuning or the
>algorithm is at fault when we get results we don't like. Have you done
>much running with the auto-tuning turned off, using the old values,
>to see the impact (positive or negative) that just the new algorithm has?
>
>

I'm not sure what you mean by self-tuning. Do you mean the scheduling
backoff stuff? Because that makes very little difference on a 16-way
NUMAQ. However it becomes critical for SGI above around 128 CPUs IIRC
so I just kept it in mind when doing sched domains.

The new balancing calculations are definitely a win in my tests. One
tiny regression (the order of 1%) I saw on the NUMAQ was tbench due to
increased idle time. But I'll still take it as a win because we were
doing nearly 1000 times less inter node balancing.

-
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:00    [W:0.075 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site