From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757132AbcH3Czq (ORCPT ); Mon, 29 Aug 2016 22:55:46 -0400 Received: from mga09.intel.com ([134.134.136.24]:30005 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754688AbcH3Czp (ORCPT ); Mon, 29 Aug 2016 22:55:45 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,254,1470726000"; d="scan'208";a="2593155" Date: Tue, 30 Aug 2016 03:00:58 +0800 From: Yuyang Du To: Morten Rasmussen Cc: Vincent Guittot , Peter Zijlstra , Ingo Molnar , linux-kernel , Benjamin Segall , Paul Turner , Dietmar Eggemann , Matt Fleming , Mike Galbraith Subject: Re: [PATCH v1 00/10] Optimize sched avgs computation and implement flat util hierarchy Message-ID: <20160829190058.GJ3273@intel.com> References: <1470788095-2125-1-git-send-email-yuyang.du@intel.com> <20160810002352.GB3273@intel.com> <20160822232637.GC3273@intel.com> <20160823141341.GP10153@twins.programming.kicks-ass.net> <20160824085434.GB3315@e105550-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160824085434.GB3315@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 On Wed, Aug 24, 2016 at 09:54:35AM +0100, Morten Rasmussen wrote: > As Dietmar mentioned already, the 'disconnect' is a feature of the PELT > rewrite. Paul and Ben's original implementation had full propagation up > and down the hierarchy. IIRC, one of the key points of the rewrite was > more 'stable' signals, which we would loose by re-introducing immediate > updates throughout hierarchy. As I mentioned earlier, no essential change! A feature perhaps is: the rewrite takes into account the runnable ratio. E.g., let there be a group having one task with share 1024, if the task sticks to one CPU, and the task is runnable 50% of the time. With the old implementation, the group_entity_load_avg is 1024; but with the rewritten implementation, the group_entity_load_avg is 512. Isn't this good? If the task migrates, the old implementation will still be 1024 on the new CPU, but the rewritten implementation will transition to 512, albeit taking 0.1+ second time, which we are now addressing. Isn't this good? > It is a significant change to group scheduling, so I'm a bit surprised > that nobody has observed any problems post the rewrite. But maybe most > users don't care about the load-balance being slightly off when tasks > have migrated or new tasks are added to a group. I don't understand what you are saying. > If we want to re-introduce propagation of both load and utilization I > would suggest that we just look at the original implementation. It > seemed to work. > > Handling utilization and load differently will inevitably result in more > code. The 'flat hierarchy' approach seems slightly less complicated, but > it prevents us from using group utilization later should we wish to do > so. It might for example become useful for the schedutil cpufreq > governor should it ever consider selecting frequencies differently based > on whether the current task is in a (specific) group or not. I understand group util may have some usage should you attempt to do so, I'm not sure how realistic it is. Nothing prevents you from knowing the current task is from which (specific) group or not.