diff options
author | Peter Zijlstra <a.p.zijlstra@chello.nl> | 2011-02-21 18:56:47 +0100 |
---|---|---|
committer | Ingo Molnar <mingo@elte.hu> | 2011-02-23 11:33:57 +0100 |
commit | 866ab43efd325fae8889ea77a744d03f2b957e38 (patch) | |
tree | 450263aa8a30abb4a0ab2812643aa7a83711df05 /kernel/sysctl.c | |
parent | cc57aa8f4b3bece8c26c7929728edcc5fa6b5aed (diff) | |
download | lwn-866ab43efd325fae8889ea77a744d03f2b957e38.tar.gz lwn-866ab43efd325fae8889ea77a744d03f2b957e38.zip |
sched: Fix the group_imb logic
On a 2*6*2 machine something like:
taskset -c 3-11 bash -c 'for ((i=0;i<9;i++)) do while :; do :; done & done'
_should_ result in 9 busy CPUs, each running 1 task.
However it didn't quite work reliably, most of the time one cpu of the
second socket (6-11) would be idle and one cpu of the first socket
(0-5) would have two tasks on it.
The group_imb logic is supposed to deal with this and detect when a
particular group is imbalanced (like in our case, 0-2 are idle but 3-5
will have 4 tasks on it).
The detection phase needed a bit of a tweak as it was too weak and
required more than 2 avg weight tasks difference between idle and busy
cpus in the group which won't trigger for our test-case. So cure that
to be one or more avg task weight difference between cpus.
Once the detection phase worked, it was then defeated by the f_b_g()
tests trying to avoid ping-pongs. In particular, this_load >= max_load
triggered because the pulling cpu (the (first) idle cpu in on the
second socket, say 6) would find this_load to be 5 and max_load to be
4 (there'd be 5 tasks running on our socket and only 4 on the other
socket).
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Nikhil Rao <ncrao@google.com>
Cc: Venkatesh Pallipadi <venki@google.com>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: Mike Galbraith <efault@gmx.de>
LKML-Reference: <new-submission>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Diffstat (limited to 'kernel/sysctl.c')
0 files changed, 0 insertions, 0 deletions