From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1753938AbcJDUQM (ORCPT <rfc822;w@1wt.eu>);
        Tue, 4 Oct 2016 16:16:12 -0400
Received: from mail-wm0-f48.google.com ([74.125.82.48]:35130 "EHLO
        mail-wm0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751223AbcJDUQL (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 4 Oct 2016 16:16:11 -0400
Date: Tue, 4 Oct 2016 21:16:07 +0100
From: Matt Fleming <matt@codeblueprint.co.uk>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>,
        Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Mike Galbraith <umgwanakikbuti@gmail.com>,
        Yuyang Du <yuyang.du@intel.com>
Subject: Re: [PATCH] sched/fair: Do not decay new task load on first enqueue
Message-ID: <20161004201607.GQ16071@codeblueprint.co.uk>
References: <20160923115808.2330-1-matt@codeblueprint.co.uk>
 <20160928101422.GR5016@twins.programming.kicks-ass.net>
 <dba1266f-6e48-ff3d-379e-fd81545fcdec@arm.com>
 <20160928111912.GU5016@twins.programming.kicks-ass.net>
 <93981a94-8aff-edc9-b964-9f31656ad577@arm.com>
 <CAKfTPtC9d8iE_jAJ9-bej886imqN2WNjsqGPP3t-CVAtiyxC-Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAKfTPtC9d8iE_jAJ9-bej886imqN2WNjsqGPP3t-CVAtiyxC-Q@mail.gmail.com>
User-Agent: Mutt/1.5.24+41 (02bc14ed1569) (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.