Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757459AbcDEH6h (ORCPT ); Tue, 5 Apr 2016 03:58:37 -0400 Received: from mga03.intel.com ([134.134.136.65]:40304 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752483AbcDEH6g (ORCPT ); Tue, 5 Apr 2016 03:58:36 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,443,1455004800"; d="scan'208";a="951867848" Date: Tue, 5 Apr 2016 08:15:52 +0800 From: Yuyang Du To: Morten Rasmussen Cc: Leo Yan , Steve Muckle , Peter Zijlstra , Ingo Molnar , Dietmar Eggemann , 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: <20160405001552.GB8697@intel.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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160405075112.GC18516@e105550-lin.cambridge.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: 1338 Lines: 27 On Tue, Apr 05, 2016 at 08:51:13AM +0100, Morten Rasmussen wrote: > On Tue, Apr 05, 2016 at 02:30:03AM +0800, Yuyang Du wrote: > > On Mon, Apr 04, 2016 at 09:48:23AM +0100, Morten Rasmussen wrote: > > > On Sat, Apr 02, 2016 at 03:11:54PM +0800, Leo Yan wrote: > > > > On Fri, Apr 01, 2016 at 03:28:49PM -0700, Steve Muckle wrote: > > > > > I think I follow - Leo please correct me if I mangle your intentions. > > > > > It's an issue that Morten and Dietmar had mentioned to me as well. > > > > > > Yes. We have been working on this issue for a while without getting to a > > > nice solution yet. > > > > So do you want a "flat hirarchy" for util_avg - just do util_avg for > > rq and task respectively? Seems it is what you want, and it is even easier? > > Pretty much, yes. I can't think of a good reason why we need the > utilization of groups as long as we have the task utilization and the > sum of those for the root cfs_rq. Sound good to me too. > I'm not saying it can't be implemented, just saying that it will make > utilization tracking for groups redundant and possibly duplicate or hack > some the existing code to implement the new root utilization sum. A initial evaluation of the implementation: it looks much easier to do (at least) than the current. Lets wait for a day or two, if no objection, then lets do it.