[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131015170507.GR31039@e103034-lin>
Date: Tue, 15 Oct 2013 18:05:07 +0100
From: Morten Rasmussen <morten.rasmussen@....com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: "mingo@...nel.org" <mingo@...nel.org>,
"pjt@...gle.com" <pjt@...gle.com>,
"arjan@...ux.intel.com" <arjan@...ux.intel.com>,
"rjw@...k.pl" <rjw@...k.pl>,
"dirk.j.brandewie@...el.com" <dirk.j.brandewie@...el.com>,
"vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
"alex.shi@...aro.org" <alex.shi@...aro.org>,
"preeti@...ux.vnet.ibm.com" <preeti@...ux.vnet.ibm.com>,
"efault@....de" <efault@....de>, "corbet@....net" <corbet@....net>,
"tglx@...utronix.de" <tglx@...utronix.de>,
Catalin Marinas <Catalin.Marinas@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linaro-kernel@...ts.linaro.org" <linaro-kernel@...ts.linaro.org>
Subject: Re: [RFC][PATCH 0/7] Power-aware scheduling v2
On Mon, Oct 14, 2013 at 06:31:13PM +0100, Peter Zijlstra wrote:
> On Mon, Oct 14, 2013 at 06:15:41PM +0100, Morten Rasmussen wrote:
> > > In fact, I don't see anything except a random bunch of hooks without an
> > > over-all picture of how to get less power used.
> >
> > I will follow up with a better description of the overall picture. The
> > slides I linked to are not really self-explaining.
>
> I hadn't even noticed there were slides linked. In general I tend to
> ignore external links -- patches should be descriptive enough to stand
> on their own.
Elaborating a bit more on the big picture and where we can go with this
proposal, here are the main requirements:
1. A unified scheduler driven power policy, i.e. the scheduler drives
DVFS/idle (as suggested by Ingo and hence this first set of patches).
2. Small task packing. Avoid spreading tasks under light workloads.
In addition for big.LITTLE we need:
3. Task placement based cpu suitability. Associate task load ranges with
each cpu to give task placement. Heavy tasks on big, small tasks on
little.
This patch set addresses part of 1, while 3 will follow soon. Point 2 is
worked on by Vincent in collaboration with us.
The power driver introduced in this set has a role in the solution to
all three points. It serves as a unified platform power driver and the
interface allows the scheduler to get highlevel feedback which cpufreq
and cpuidle do not currently provide.
Decisions about the power/performance trade-off will be made in the
power driver guided by the hints from the scheduler. That allow
platforms the freedom to do what they want with the hints including
ignoring them completely (taking Arjan's previous comments into
account). It will make the power driver much powerful than the current
cpufreq/cpuidle drivers.
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/
Powered by blists - more mailing lists