lkml.org 
[lkml]   [2015]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFCv3 PATCH 00/48] sched: Energy cost model for energy-aware scheduling
On Thu, Apr 09, 2015 at 08:41:34AM +0100, Vincent Guittot wrote:
> On 8 April 2015 at 15:33, Morten Rasmussen <morten.rasmussen@arm.com> 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 <morten.rasmussen@arm.com> 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


\
 
 \ /
  Last update: 2015-04-10 17:21    [W:0.168 / U:0.452 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site