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

["Iyer, Sundar" <sundar.iyer@intel.com>]

> -----Original Message-----
> From: ksummit-discuss-bounces@lists.linuxfoundation.org [mailto:ksummit-
> discuss-bounces@lists.linuxfoundation.org] On Behalf Of Peter Zijlstra

> > (http://marc.info/?t=139834240600003&r=1&w=4) it became apparent that

> > First of all, it would be good to have a place where subsystems and
> > device drivers can go and check what the current "energy conservation
> > bias" is in case they need to make a decision between delivering more
> > performance and using less energy.  Second, it would be good to

It might sound a stupid question, but isn't this entirely dependent on the platform?

A higher performance will translate into better energy only if the "race to halt" was
true and the system/platform had a nice power/performance/energy curve. E.g. if the
task got completed quicker enough (reduced t) to offset the most probably increased
current consumption (increased i @ constant v).

Am I wrong? What would happen on a platform, where more performance means
using more energy?

> > provide user space with a means to tell the kernel whether it should
> > care more about performance or energy.  Finally, it would be good to
> > be able to adjust the overall "energy conservation bias" automatically

Instead of either energy or performance, would it be easier to look if
it were a "just enough performance" metric? Rather than worry about a reduced
performance to save energy, it would be IMO better to try to optimize the energy
within the constraints of the required performance. Of course, those constraints
could be changed.

e.g. if the display would communicate it doesn't need to refresh more than 60fps,
this could be communicated to the GPU/CPU to control the bias for these sub-systems
accordingly.

> > in response to certain "power" events such as "battery is low/critical" etc.

Would I be wrong if I said the thermal throttling is already an example of this?
When the battery is critical/temperature is unbearable, the system cuts down
the performance of sub-systems like CPU, display etc.

> per-subsystem sounds right to me; I don't care which particular instance of
> graphics cards I have, I want whichever one(s) I have to obey.
> 
> global doesn't make sense, like stated earlier I absolutely detest automagic
> backlight dimming, whereas I don't particularly care about compute speed at
> all.

That calls for highly customized preferences for what to control: in most cases
the dimmed backlight itself saves a considerable amount of energy which wouldn't
be matched by a CPU (or a GPU) control. On a battery device, the first preference
would be to dim out the screen but still allow the user a good battery life and 
user experience.

Cheers!