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 S1753410AbcI1SAD (ORCPT <rfc822;w@1wt.eu>);
        Wed, 28 Sep 2016 14:00:03 -0400
Received: from foss.arm.com ([217.140.101.70]:41544 "EHLO foss.arm.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1752973AbcI1R7y (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 28 Sep 2016 13:59:54 -0400
Subject: Re: [PATCH] sched/fair: Do not decay new task load on first enqueue
To: Peter Zijlstra <peterz@infradead.org>
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>
Cc: Matt Fleming <matt@codeblueprint.co.uk>,
        Ingo Molnar <mingo@kernel.org>, linux-kernel@vger.kernel.org,
        Mike Galbraith <umgwanakikbuti@gmail.com>,
        Yuyang Du <yuyang.du@intel.com>,
        Vincent Guittot <vincent.guittot@linaro.org>
From: Dietmar Eggemann <dietmar.eggemann@arm.com>
Message-ID: <b50a9fe5-41af-d690-3fec-39434eb7c1ae@arm.com>
Date: Wed, 28 Sep 2016 18:59:52 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <20160928111912.GU5016@twins.programming.kicks-ass.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 28/09/16 12:19, Peter Zijlstra wrote:
> On Wed, Sep 28, 2016 at 12:06:43PM +0100, Dietmar Eggemann wrote:
>> On 28/09/16 11:14, Peter Zijlstra wrote:
>>> On Fri, Sep 23, 2016 at 12:58:08PM +0100, Matt Fleming wrote:

[...]

>> I'm afraid that with accurate timing we will get the same situation that
>> we add and subtract the same amount of load (probably 1024 now and not
>> 1002 (or less)) to/from cfs_rq->runnable_load_avg for the initial (fork)
>> hackbench run.
>> After all, it's 'runnable' based.
> 
> The idea was that since we now update rq clock before post_init and then
> leave it be, both post_init and enqueue see the exact same timestamp,
> and the delta is 0, resulting in no aging.
> 
> Or did I fail to make that happen?

No, you're right the task load ages from 1024 (enqueue) to something
between 1002 and 1024 in (dequeue) for the initial fork-phase.

The call to __update_load_avg() in enqueue_task_fair() is now always
done with 'delta = now - sa->last_update_time' equal 0 so we bail out.

The following call to __update_load_avg() (from dequeue_task_fair(), or
set_next_entity() or even task_tick_fair()) let us enter the 'decayed =
1' path (even for a short runtime (>1us) since the initial value for
period_contrib is 1023 and with the initial values of load_avg=1024 and
load_sum = 1024*47742 = 48,887,808 (and a runtime < 1001us, so contrib
stays 0) we end up decaying load_avg to something between 1002 and 1024.