* Nick Piggin <[email protected]> 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 <[email protected]>
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 <[email protected]>
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |