![]() | ||||||||||
Messages in this thread |
Peter Williams wrote: > Peter Williams wrote: > >> Con Kolivas wrote: >> >>> On Wed, 11 Jan 2006 01:38 pm, Peter Williams wrote: >>> >>>> Con Kolivas wrote: >>>> > I guess we need to check whether reversing this patch helps. >>>> >>>> It would be interesting to see if it does. >>>> >>>> If it does we probably have to wear the cost (and try to reduce it) as >>>> without this change smp nice support is fairly ineffective due to the >>>> fact that it moves exactly the same tasks as would be moved without >>>> it. >>>> At the most it changes the frequency at which load balancing occurs. >>> >>> >>> >>> >>> I disagree. I think the current implementation changes the balancing >>> according to nice much more effectively than previously where by >>> their very nature, low priority tasks were balanced more frequently >>> and ended up getting their own cpu. >> >> >> >> I can't follow the logic here and I certainly don't see much >> difference in practice. > > > I think I've figured out why I'm not seeing much difference in > practice. I'm only testing on 2 CPU systems and it seems to me that > the main difference that the SMP nice patch will have is in selecting > which CPU to steal tasks from (grabbing the one with the highest > priority tasks) and this is a non issue on a 2 CPU system. :-( > > So I should revise my statement to say that it doesn't make much > difference if there's only 2 CPUs. > If nothing's niced, why would it be affecting scheduling decisions at all? That seems broken to me ? M. - 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: 2006-01-11 06:24 [from the cache] ©2003-2008 | ||||||||||