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

[Morten Rasmussen]

On Tue, May 06, 2014 at 04:39:56PM +0100, Peter Zijlstra wrote:
> On Tue, May 06, 2014 at 03:51:25PM +0100, Morten Rasmussen wrote:
> > On Tue, May 06, 2014 at 02:49:09PM +0100, Peter Zijlstra wrote:
> > > On Tue, May 06, 2014 at 02:54:03PM +0200, Rafael J. Wysocki wrote:
> > > > Hi All,
> > > > 
> > > > During a recent discussion on linux-pm/LKML regarding the integration of the
> > > > scheduler with cpuidle (http://marc.info/?t=139834240600003&r=1&w=4) it became
> > > > apparent that the kernel might benefit from adding interfaces to let it know
> > > > how far it should go with saving energy, possibly at the expense of performance.
> > > > 
> > > > 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 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 in response to certain "power" events such
> > > > as "battery is low/critical" etc.
> > > > 
> > > > It doesn't seem to be clear currently what level and scope of such interfaces
> > > > is appropriate and where to place them.  Would a global knob be useful?  Or
> > > > should they be per-subsystem, per-driver, per-task, per-cgroup etc?
> > > 
> > > per-task and per-cgroup doesn't seem to make sense to me; its the
> > > hardware that consumes energy.
> > 
> > True. But performance requirements are associated with tasks or groups
> > of tasks. We also need an interface to get input from userspace to tell
> > us when it is acceptable to potentially loose performance to save
> > energy. IIUC, that is Rafael's second point above.
> 
> That's the QoS thing. While related I don't think we should confuse the
> two.

Fully agree. We need both.