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

[Peter Zijlstra <peterz@infradead.org>]

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.