Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965052AbbLOKLF (ORCPT ); Tue, 15 Dec 2015 05:11:05 -0500 Received: from mga14.intel.com ([192.55.52.115]:36344 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964841AbbLOKLB (ORCPT ); Tue, 15 Dec 2015 05:11:01 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,431,1444719600"; d="scan'208";a="13431672" Date: Tue, 15 Dec 2015 10:24:32 +0800 From: Yuyang Du To: Steve Muckle Cc: Peter Zijlstra , Ingo Molnar , Morten Rasmussen , Dietmar Eggemann , Patrick Bellasi , Juri Lelli , Vincent Guittot , "linux-kernel@vger.kernel.org" Subject: Re: PELT initial task load and wake_up_new_task() Message-ID: <20151215022432.GG28098@intel.com> References: <566B8009.2090006@linaro.org> <20151213191319.GA28098@intel.com> <566F61AA.4020904@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <566F61AA.4020904@linaro.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1463 Lines: 33 On Mon, Dec 14, 2015 at 04:41:14PM -0800, Steve Muckle wrote: > Hi Yuyang, > > On 12/13/2015 11:13 AM, Yuyang Du wrote: > > Hi Steve, > > > > On Fri, Dec 11, 2015 at 06:01:45PM -0800, Steve Muckle wrote: > >> In init_entity_runnable_average() the last_update_time is initialized to > >> zero. The task is given max load and utilization as a pessimistic > >> initial estimate. > >> > >> But if in wake_up_new_task() the task is placed on a CPU other than > >> where it was created, __update_load_avg() will be called via > >> set_task_cpu() -> migrate_task_rq_fair() -> remove_entity_load_avg(). > >> > >> Since last_update_time is zero the delta will be huge and the task's > >> load will be entirely decayed away before it is enqueued at the > >> destination CPU. > > > > Since the new task's last_update_time is equal to 0, it will not be decayed. > > Can you point me to the code for that logic? I don't see anything that > prevents the decay when a newly woken task is placed on a different CPU > via the call chain I mentioned above. My testing also shows the load > being decayed to zero. > You may search the last_update_time, and see it would be treated differently if it is 0. Hope this may be helpful. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/