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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKfTPtB=Fh4KynRpeZgu22BVayMFkcA6LdfPJgige5urmSEAJA@mail.gmail.com>
Date:	Thu, 9 Apr 2015 09:41:34 +0200
From:	Vincent Guittot <vincent.guittot@...aro.org>
To:	Morten Rasmussen <morten.rasmussen@....com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	"mingo@...hat.com" <mingo@...hat.com>,
	Dietmar Eggemann <Dietmar.Eggemann@....com>,
	Yuyang Du <yuyang.du@...el.com>,
	Preeti U Murthy <preeti@...ux.vnet.ibm.com>,
	Mike Turquette <mturquette@...aro.org>,
	Nicolas Pitre <nico@...aro.org>,
	"rjw@...ysocki.net" <rjw@...ysocki.net>,
	Juri Lelli <Juri.Lelli@....com>,
	linux-kernel <linux-kernel@...r.kernel.org>
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@....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@....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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/