Messages in this thread | | | From | Vincent Guittot <> | Date | Thu, 9 Apr 2015 09:41:34 +0200 | Subject | Re: [RFCv3 PATCH 00/48] sched: Energy cost model for energy-aware scheduling |
| |
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 ?
Regards, Vincent
> > 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.
that's fair enough
> > Thanks, > Morten
| |