From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754070AbbDHNcT (ORCPT ); Wed, 8 Apr 2015 09:32:19 -0400 Received: from foss.arm.com ([217.140.101.70]:50587 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753070AbbDHNcR (ORCPT ); Wed, 8 Apr 2015 09:32:17 -0400 Date: Wed, 8 Apr 2015 14:33:03 +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: <20150408133303.GA10138@e105550-lin.cambridge.arm.com> References: <1423074685-6336-1-git-send-email-morten.rasmussen@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 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 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 would still include them in updated mega-postings that includes all the dependencies so the full story would still available for those who are interested. I would of course make it clear which patches that are also posted separately. Thanks, Morten