Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756262AbbDJOpk (ORCPT ); Fri, 10 Apr 2015 10:45:40 -0400 Received: from foss.arm.com ([217.140.101.70]:55714 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754911AbbDJOpj (ORCPT ); Fri, 10 Apr 2015 10:45:39 -0400 Date: Fri, 10 Apr 2015 15:46:31 +0100 From: Morten Rasmussen To: Vincent Guittot Cc: Peter Zijlstra , "mingo@redhat.com" , Dietmar Eggemann , Yuyang Du , Preeti U Murthy , Mike Turquette , Nicolas Pitre , "rjw@rjwysocki.net" , Juri Lelli , linux-kernel Subject: Re: [RFCv3 PATCH 00/48] sched: Energy cost model for energy-aware scheduling Message-ID: <20150410144631.GF8014@e105550-lin.cambridge.arm.com> References: <1423074685-6336-1-git-send-email-morten.rasmussen@arm.com> <20150408133303.GA10138@e105550-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: 3350 Lines: 71 On Thu, Apr 09, 2015 at 08:41:34AM +0100, Vincent Guittot wrote: > On 8 April 2015 at 15:33, Morten Rasmussen wrote: > > Hi Vincent, > > > > On Thu, Apr 02, 2015 at 01:43:31PM +0100, Vincent Guittot wrote: > >> On 4 February 2015 at 19:30, Morten Rasmussen wrote: > >> > RFCv3 is a consolidation of the latest energy model related patches and > >> > previously posted patch sets related to capacity and utilization > >> > tracking [2][3] to show where we are heading. [2] and [3] have been > >> > rebased onto v3.19-rc7 with a few minor modifications. Large parts of > >> > the energy model code and use of the energy model in the scheduler has > >> > been rewritten and simplified. The patch set consists of three main > >> > parts (more details further down): > >> > > >> > Patch 1-11: sched: consolidation of CPU capacity and usage [2] (rebase) > >> > > >> > Patch 12-19: sched: frequency and cpu invariant per-entity load-tracking > >> > and other load-tracking bits [3] (rebase) > >> > > >> > Patch 20-48: sched: Energy cost model for energy-aware scheduling (RFCv3) > >> > >> > >> Hi Morten, > >> > >> 48 patches is a big number of patches and when i look into your > >> patchset, some feature are quite self contained. IMHO it would be > >> worth splitting it in smaller patchsets in order to ease the review > >> and the regression test. > >> From a 1st look at your patchset , i have found > >> -patches 11,13,14 and 15 are only linked to frequency scaling invariance > >> -patches 12, 17 and 17 are only about adding cpu scaling invariance > >> -patches 18 and 19 are about tracking and adding the blocked > >> utilization in the CPU usage > >> -patches 20 to the end is linked the EAS > > > > I agree it makes sense to regroup the patches as you suggest. A better > > logical ordering should make the reviewing a less daunting task. I'm a > > bit hesitant to float many small sets of patches as their role in the > > bigger picture would be less clear and hence risk loosing the 'why'. > > IMHO, it should be as easy (if not easier) to review and pick patches in > > a larger set as it is for multiple smaller sets. However, I guess that > > Having self contained patchset merged in a larger set can create so > useless dependency between them as they modify same area but for > different goal > > > is individual and for automated testing it would be easier to have them > > split out. > > > > How about focusing on one (or two) of these smaller patch sets at the > > time to minimize the potential confusion and post them separately? > > I'm fine with your proposal to start with 1 or 2 smaller patchset. The > 2 following patchset are, IMHO, the ones the most self contained and > straight forward: > - patches 11,13,14 and 15 are only linked to frequency scaling invariance > - patches 18 and 19 are about tracking and adding the blocked > utilization in the CPU usage > > May be we can start with them ? Agreed. Those two would form meaningful patch sets. I will fix them and split them out. Thanks, Morten -- 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/