From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753250AbcI1LbT (ORCPT ); Wed, 28 Sep 2016 07:31:19 -0400 Received: from foss.arm.com ([217.140.101.70]:35870 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752339AbcI1LbL (ORCPT ); Wed, 28 Sep 2016 07:31:11 -0400 Subject: Re: [PATCH] sched/fair: Do not decay new task load on first enqueue To: Peter Zijlstra References: <20160923115808.2330-1-matt@codeblueprint.co.uk> <20160928101422.GR5016@twins.programming.kicks-ass.net> <20160928111912.GU5016@twins.programming.kicks-ass.net> Cc: Matt Fleming , Ingo Molnar , linux-kernel@vger.kernel.org, Mike Galbraith , Yuyang Du , Vincent Guittot From: Dietmar Eggemann Message-ID: <93981a94-8aff-edc9-b964-9f31656ad577@arm.com> Date: Wed, 28 Sep 2016 12:31:07 +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: 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: [...] >> Not sure what you mean by 'after fixing' but the se is initialized with >> a possibly stale 'now' value in post_init_entity_util_avg()-> >> attach_entity_load_avg() before the clock is updated in >> activate_task()->enqueue_task(). > > I meant that after I fix the above issue of calling post_init with a > stale clock. So the + update_rq_clock(rq) in the patch. OK. [...] >>> While staring at this, I don't think we can still hit >>> vruntime_normalized() with a new task, so I _think_ we can remove that >>> !se->sum_exec_runtime clause there (and rejoice), no? >> >> 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, but IMHO what Matt wants is ageing for the hackench tasks at the end of their fork phase so there is a tiny amount of cfs_rq->runnable_load_avg left on cpuX after the fork related dequeue so the (load-based) fork-balancer chooses cpuY for the next hackbench task. That's why he wanted to avoid the __update_load_avg(se) on enqueue (thus adding 1024 to cfs_rq->runnable_load_avg) and do the ageing only on dequeue (removing <1024 from cfs_rq->runnable_load_avg).