gnome-power-manager-2.22's /apps/gnome-power-manager/cpufreq/consider_nice gconf key defaults to false in the schemas, which means that on a system running gnome-power-manager and ondemand, the /sys/devices/system/cpu/cpu*/cpufreq/ondemand/ignore_nice_load sysfs configuration will be 1 out of the box. This is a problem, _especially_ in Gentoo, but I believe also generally. It means that on any system that has a scalable frequency CPU with that enabled in the kernel, niced processes will not ramp up the CPU frequency, leading to the work getting done in a larger time span, meaning less possibility to be in lower C states, meaning more power usage. In a Gentoo context it also means that with a positive PORTAGE_NICENESS set, portage (emerge) operations are not running at full speed. On my laptop that means approximately 3 times longer (wall clock) package installation/upgrade time, as it's doing it at 800MHz instead of 2400MHz. The only case where this might make sense in my opinion is when e.g nice levels of 19 are used for stuff like seti@home or folding@home. But I believe those should set an idle process priority class instead and power management decisions done based on that (I'm not sure if they are or not). This bug is mainly as a reminder to, well, fix it, and consider with it when forward porting cpufreq support to gnome-power-manager-2.24. Also importantly to gather any objections. If you have any - state them here. Thanks.
Fixed in overlay. Thanks for reporting.
