| commit | de69a80be32445b0a71e8e3b757e584d7beb90f7 | |
| author | Peter Zijlstra <a.p.zijlstra@chello.nl> | |
| Thu, 17 Sep 2009 07:01:20 +0000 (17 09:01 +0200) | ||
| committer | Ingo Molnar <mingo@elte.hu> | |
| Thu, 17 Sep 2009 08:40:30 +0000 (17 10:40 +0200) | ||
| tree | 3a8d6bf8e5aded3c371e5dc090b8874305952d1f | treesnapshot (tar.gz zip) |
| parent | ad4b78bbcbab66998b05d422ac6106b645796e54 | commitdiff |
sched: Stop buddies from hogging the system
Clear buddies more agressively.
The (theoretical, haven't actually observed any of this) problem is
that when we do not select either buddy in pick_next_entity()
because they are too far ahead of the left-most task, we do not
clear the buddies.
This means that as soon as we service the left-most task, these
same buddies will be tried again on the next schedule. Now if the
left-most task was a pure hog, it wouldn't have done any wakeups
and it wouldn't have set buddies of its own. That leads to the old
buddies dominating, which would lead to bad latencies.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Galbraith <efault@gmx.de>
LKML-Reference: <new-submission>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Clear buddies more agressively.
The (theoretical, haven't actually observed any of this) problem is
that when we do not select either buddy in pick_next_entity()
because they are too far ahead of the left-most task, we do not
clear the buddies.
This means that as soon as we service the left-most task, these
same buddies will be tried again on the next schedule. Now if the
left-most task was a pure hog, it wouldn't have done any wakeups
and it wouldn't have set buddies of its own. That leads to the old
buddies dominating, which would lead to bad latencies.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Galbraith <efault@gmx.de>
LKML-Reference: <new-submission>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
| kernel/sched_fair.c | diffblobblamehistory |