Re: [RFCv3 PATCH 00/48] sched: Energy cost model for energy-aware scheduling

[Morten Rasmussen]

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@xxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/