sched: Do less agressive buddy clearing
authorPeter Zijlstra <a.p.zijlstra@chello.nl>
Fri, 9 Oct 2009 10:43:07 +0000 (12:43 +0200)
committerIngo Molnar <mingo@elte.hu>
Wed, 14 Oct 2009 13:02:34 +0000 (15:02 +0200)
commit92f6a5e37a2e2d3342dafb2b39c2f8bc340bbf84
tree1e71e909fbf74b09863815549dbbe67d1661ab2b
parent799e2205ec65e174f752b558c62a92c4752df313
sched: Do less agressive buddy clearing

Yanmin reported a hackbench regression due to:

 > commit de69a80be32445b0a71e8e3b757e584d7beb90f7
 > Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
 > Date:   Thu Sep 17 09:01:20 2009 +0200
 >
 >     sched: Stop buddies from hogging the system

I really liked de69a80b, and it affecting hackbench shows I wasn't
crazy ;-)

So hackbench is a multi-cast, with one sender spraying multiple
receivers, who in their turn don't spray back.

This would be exactly the scenario that patch 'cures'. Previously
we would not clear the last buddy after running the next task,
allowing the sender to get back to work sooner than it otherwise
ought to have been, increasing latencies for other tasks.

Now, since those receivers don't poke back, they don't enforce the
buddy relation, which means there's nothing to re-elect the sender.

Cure this by less agressively clearing the buddy stats. Only clear
buddies when they were not chosen. It should still avoid a buddy
sticking around long after its served its time.

Reported-by: "Zhang, Yanmin" <yanmin_zhang@linux.intel.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
CC: Mike Galbraith <efault@gmx.de>
LKML-Reference: <1255084986.8802.46.camel@laptop>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
kernel/sched_fair.c