2016-10-04 20:16:12

by Matt Fleming

[permalink] [raw]
Subject: Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Wed, 28 Sep, at 04:46:06AM, Vincent Guittot wrote:
>
> ok so i'm a bit confused there
> my understand of your explanation above is that now we left a small
> amount of load in runnable_load_avg after the dequeue so another cpu
> will be chosen. But this explanation seems to be the opposite of what
> Matt said in a previous email that:
> "The performance drop comes from the fact that enqueueing/dequeueing a
> task with load 1002 during fork() results in a zero runnable_load_avg,
> which signals to the load balancer that the CPU is idle, so the next
> time we fork() we'll pick the same CPU to enqueue on -- and the cycle
> continues."

Right, we want to avoid the performance drop, which we can do by
leaving a small amount of load in runnable_load_avg. I think Dietmar
and me are saying the same thing.