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 Rafael J.
> Wysocki
> Sent: Thursday, May 8, 2014 6:28 PM
 
> That's something I was thinking about too, but the difficulty here is in how to
> define the profiles (that is, what settings in each subsystem are going to be
> affected by a profile change) and in deciding when to switch profiles and
> which profile is the most appropriate going forward.
> 
> IOW, the high-level concept looks nice, but the details of the implementation
> are important too. :-)

I agree. Defining these profiles and trying to fit them into a system definition, 
system usage policy and above all user usage policy is where the sticking point is.

> > Today cpuidle and cpufreq already expose these settings through
> > governors.
> 
> cpufreq governors are kind of tied to specific "energy efficiency" profiles,
> performance, powersave, on-demand.  However, cpuidle governors are

I am not sure if that is correct. IMO Cpufreq governors function simply as per
policies defined to meet user experience. A system may choose to sacrifice
user experience @ the cost of running the CPU at the lowest frequency, but the
governor has no idea if it was really energy efficient for the platform. Similarly,
the governor might decide to run at a higher turbo frequency for better user
responsiveness, but it still doesn't know if it was energy efficient running @ those
frequencies. I am coming back to the point that energy efficiency is countable
_only_ at the platform level: if it results in a longer battery life w/o needing to plug in.

> > Look at an example for a tuned profile for performance:
> > start() gets called when the profile is switched to and stop() when
> > its turned off. We could include the scheduling parameters in the
> > profile when we come up with the set of them.
> >
> >  start() {
> >      [ "$USB_AUTOSUSPEND" = 1 ] && enable_usb_autosuspend
> >      set_disk_alpm min_power
> >      enable_cpu_multicore_powersave
> >      set_cpu_governor ondemand
> >      enable_snd_ac97_powersave
> >      set_hda_intel_powersave 10
> >      enable_wifi_powersave
> >      set_radeon_powersave auto
> >      return 0
> >  }
> >
> >  stop() {
> >      [ "$USB_AUTOSUSPEND" = 1 ] && disable_usb_autosuspend
> >      set_disk_alpm max_performance
> >      disable_cpu_multicore_powersave
> >      restore_cpu_governor
> >      restore_snd_ac97_powersave
> >      restore_hda_intel_powersave
> >      disable_wifi_powersave
> >      restore_radeon_powersave
> >      return 0
> >  }
> 
> You seem to think that user space would operate those profiles, but the
> experience so far is that user space is not actually good at doing things like
> that.  We have exposed a number of PM-related knobs to user space, but in
> may cases it actively refuses to use them (we have dropped a couple of
> them too for this very reason).

Please correct me if I am wrong, but items like wifi_powersave are something
default on most systems especially with per-device runtime power management.
Most devices are runtime managed and I don't see a strong reason to switch
device policies as energy saving methods.

> > A global knob would be useful in the case where the user chooses
> > performance policy for example. It means he expects the kernel to
> > *never* sacrifice performance for powersave. Now assume that a set of
> > tasks is running on 4 cpus out of 10. If the user has chosen
> > performance policy, *none of the 10 cpus should enter deep idle
> > states* lest they affect the latency of the tasks. Here a global knob would
> do well.

For this specific example, when you say the *user* has chosen the policy, do
you mean a user space daemon that takes care of this or the application itself?

How are we going to know if we will really save energy by limiting deep idle states
on all the 10 CPUs? Please help me understand this.

Cheers!