• P
    sched: Fix the group_imb logic · 866ab43e
    Peter Zijlstra 提交于
    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: NPeter 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: NIngo Molnar <mingo@elte.hu>
    866ab43e
sched_fair.c 108.4 KB