![]() | |||||||||||
Messages in this thread |
* Nick Piggin <nickpiggin@yahoo.com.au> wrote: > During periodic load balancing, don't hold this runqueue's lock while > scanning remote runqueues, which can take a non trivial amount of time > especially on very large systems. > > Holding the runqueue lock will only help to stabalise ->nr_running, s/stabalise/stabilise/ > however this isn't doesn't do much to help because tasks being woken s/isn't // > will simply get held up on the runqueue lock, so ->nr_running would > not provide a really accurate picture of runqueue load in that case > anyway. > > What's more, ->nr_running (and possibly the cpu_load averages) of > remote runqueues won't be stable anyway, so load balancing is always > an inexact operation. > > Signed-off-by: Nick Piggin <npiggin@suse.de> btw., holding the runqueue lock during the initial scanning portion of load-balancing is one of the top PREEMPT_RT critical paths on SMP. (It's not bad, but it's one of the factors that makes SMP latencies higher.) Acked-by: Ingo Molnar <mingo@elte.hu> Ingo - 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-08-03 10:03 [from the cache] ©2003-2008 | |||||||||||