Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760935AbcDFIea (ORCPT ); Wed, 6 Apr 2016 04:34:30 -0400 Received: from foss.arm.com ([217.140.101.70]:55576 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754797AbcDFIe2 (ORCPT ); Wed, 6 Apr 2016 04:34:28 -0400 Date: Wed, 6 Apr 2016 09:37:04 +0100 From: Morten Rasmussen To: Dietmar Eggemann Cc: Yuyang Du , Leo Yan , Steve Muckle , Peter Zijlstra , Ingo Molnar , Vincent Guittot , linux-kernel@vger.kernel.org, eas-dev@lists.linaro.org Subject: Re: [PATCH RFC] sched/fair: let cpu's cfs_rq to reflect task migration Message-ID: <20160406083702.GE18516@e105550-lin.cambridge.arm.com> References: <1459528717-17339-1-git-send-email-leo.yan@linaro.org> <20160401194948.GN3448@twins.programming.kicks-ass.net> <56FEF621.3070404@linaro.org> <20160402071154.GA7046@leoy-linaro> <20160404084821.GA18516@e105550-lin.cambridge.arm.com> <20160404183003.GA8697@intel.com> <20160405075112.GC18516@e105550-lin.cambridge.arm.com> <20160405001552.GB8697@intel.com> <5703EF38.2060204@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5703EF38.2060204@arm.com> 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: 1501 Lines: 31 On Tue, Apr 05, 2016 at 06:00:40PM +0100, Dietmar Eggemann wrote: > @@ -2893,8 +2906,12 @@ static void attach_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *s > se->avg.last_update_time = cfs_rq->avg.last_update_time; > cfs_rq->avg.load_avg += se->avg.load_avg; > cfs_rq->avg.load_sum += se->avg.load_sum; > - cfs_rq->avg.util_avg += se->avg.util_avg; > - cfs_rq->avg.util_sum += se->avg.util_sum; > + > + if (!entity_is_task(se)) > + return; > + > + rq_of(cfs_rq)->cfs.avg.util_avg += se->avg.util_avg; > + rq_of(cfs_rq)->cfs.avg.util_sum += se->avg.util_sum; To me it seems that you cannot be sure that the rq_of(cfs_rq)->cfs.avg time stamp is aligned with se->avg time stamp, which is necessary before you can add/subtract two geometric series without introducing an error. attach_entity_load_avg() is called (through a couple of other functions) from the for_each_sched_entity() loop in enqueue_task_fair() which works its way towards the root cfs_rq, i.e. rq_of(cfs_rq)->cfs. So in the loop iteration where you attach the task sched_entity, we haven't yet visited and updated rq_of(cfs_rq)->cfs.avg. If you just add the task contribution and discover later that there is a time delta when you update rq_of(cfs_rq)->cfs.avg you end up decaying the task contribution which was already up-to-date and its util contribution to rq_of(cfs_rq)->cfs.avg ends up being smaller than it should be. Am I missing something?