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. 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. So while I might want a energy conserving bias for say the CPU and GPU, I most definitely don't want that to dim the screen. > 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? Yeah, fun.. we're not even sure how to make it do the 0,1 variants, and now you want a sliding scale to make it do in-betweens ;-)