Re: [Ksummit-discuss] [TECH(CORE?) TOPIC] Energy conservation bias interfaces

["Rafael J. Wysocki" <rjw@rjwysocki.net>]

On Tuesday, May 13, 2014 10:59:29 AM Morten Rasmussen wrote:
> On Tue, May 13, 2014 at 06:52:01AM +0100, Amit Kucheria wrote:
> > On Mon, May 12, 2014 at 6:01 PM, Morten Rasmussen
> > <morten.rasmussen@arm.com> wrote:
> > > On Mon, May 12, 2014 at 12:53:11PM +0100, Amit Kucheria wrote:
> > >> On Tue, May 6, 2014 at 6:24 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > 
> > <snip>
> > 
> > > The middleware power manager as you mention above seems to be a good
> > > candidate. The kernel wouldn't know which tasks are trusted to behave
> > > nicely so I think that is a user-space/middleware problem to deal with.
> > >
> > >>
> > >> > It also is not particularly clear what representation of "energy conservation
> > >> > bias" would be most useful.  Should that be a number or a set of well-defined
> > >> > discrete levels that can be given names (like "max performance", "high
> > >> > prerformance", "balanced" etc.)?  If a number, then what units to use and
> > >> > how many different values to take into account?
> > >>
> > >> I have a hard time figuring out how to map these levels to performance
> > >> / power optimisations I care about. Say I have the following
> > >> optimisation techniques available today that I can change at runtime.
> > >>
> > >> #define XX_TASK_PACKING              0x00000001  /* opposite of the
> > >> default spread policy */
> > >> #define XX_DISABLE_OVERDRIVE    0x00000002  /* disables expensive P-states */
> > >> #define XX_FORCE_DEEP_IDLE        0x00000004  /* go to deep idle
> > >> states even if activity on system dictates low-latency idling - useful
> > >> for thermal throttling aka idle injection */
> > >> #define XX_FORCE_SHALLOW_IDLE 0x00000008  /* keep cpu in low-latency
> > >> idle states for performance reasons */
> > >> #define XX_FOO_TECHNIQUE           0x00000010
> > >>
> > >> This is a mix of power and performance objectives that apply on a
> > >> per-cpu and/or per-cluster level. The challenge here is the lack of
> > >> consistency - some of these conflict with each other but are not
> > >> necessary opposites of each other. Some of them are good for
> > >> performance and power. How do I categorize them into 'max
> > >> performance', 'balanced' or 'power save' ?
> > >
> > > You can't. Since platforms are different, different techniques will have
> > > different impacts on the performance/energy trade-off. As I have said in
> > > the original thread, we need to distinguish between techniques to change
> > > behaviour (like the ones you have listed above) and optimization goals.
> > > Whether a specific technique can bring us closer to our current
> > > optimization goal (performance/energy trade-off) depends on the
> > > platform.
> > 
> > Right. So we are saying that state names like "powersave",
> > "balanced/auto", "performance" will be platform-defined. Is it worth
> > defining them at all then?
> 
> No. I see "powersave", "auto", and "balance/auto" as objectives.
> Objectives are platform independent. If we want stay within a certain
> energy budget, for example consume less than X joules for playing one
> hour of music, we set the performance/energy knob accordingly. It is
> then up to the kernel to apply the right techniques to achieve the
> objective on the particular platform. That will of course mean that the
> kernel needs to be better informed about the platform energy
> characteristics than it is today.
> 
> It is really a question of where we want to put all the details about
> the platform. In user-space and let some daemon control a long list of
> kernel parameters, or in the kernel and have a simple objective
> user-space interface where the performance/energy trade-off can be
> tuned (like the energy cost target as Rafael proposed).
> 
> > I expect that these techniques can be counted on our fingers, so why
> > not just expose them directly to the system? The middleware and even
> > other kernel subsystems can directly toggle their state based on
> > current conditions.
> 
> It might make sense for controlling subsystems like (GPU, wifi,
> modem,...) as middleware should often have a very good idea about which
> subsystems that are in use. However, the techniques for scheduling might
> not be either on or off. For example, task packing might make sense to
> a certain degree under certain circumstances that cannot been seen from
> user-space. The scheduler has access to detailed task information like
> load averages and wake-up counts, which might necessary to determine
> when to apply a specific technique. Forcing deep idle to reduce power
> could potentially have the exact opposite effect if applied in scenarios
> with frequent wake-ups as you risk burning more energy during the
> transitions than you save while in deep idle.
> 
> IMHO, exposing the techniques to user-space implies exporting most of
> the energy-awarness problem to user-space. My concern is that the
> interface will become complicated and the user-space daemon needs to be
> strictly in sync with the kernel. A simple(r) objective interface
> (energy cost target for scheduling/idle/freq, subsystems not in use,
> ...) might be easier use and maintain.

Precisely.

In addition to that, the CPU scheduler is not the only subsystem where
things may not be either on or off.  Take the graphics for example (at
least in the case of more complicated adapters).  There certainly are
energy efficiency vs performance tradeoffs there.

Thanks!

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.