Re: [PATCH] sched/fair: Do not decay new task load on first enqueue
From: Matt Fleming
Date: Tue Oct 04 2016 - 16:16:17 EST
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.