Avoid the cache buddies from biasing the time distribution away
from fork()ers. Normally the next buddy will be the preferred
scheduling target, but this makes fork()s prefer to run the new
child, whereas we prefer to run the parent, since that will
generate more work.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
  * wake flags
  */
 #define WF_SYNC                0x01            /* waker goes to sleep after wakup */
+#define WF_FORK                0x02            /* child wakeup after fork */
 
 struct sched_class {
        const struct sched_class *next;
 
                inc_nr_running(rq);
        }
        trace_sched_wakeup_new(rq, p, 1);
-       check_preempt_curr(rq, p, 0);
+       check_preempt_curr(rq, p, WF_FORK);
 #ifdef CONFIG_SMP
        if (p->sched_class->task_wake_up)
                p->sched_class->task_wake_up(rq, p);
 
         */
        if (sched_feat(LAST_BUDDY) && likely(se->on_rq && curr != rq->idle))
                set_last_buddy(se);
-       if (sched_feat(NEXT_BUDDY))
+       if (sched_feat(NEXT_BUDDY) && !(flags & WF_FORK))
                set_next_buddy(pse);
 
        /*