Re: [PATCH 2/3] sched: idle: Add sched balance option

From: Daniel Lezcano
Date: Fri Apr 25 2014 - 13:01:37 EST


On 04/25/2014 03:20 PM, Peter Zijlstra wrote:
On Fri, Apr 25, 2014 at 01:46:53PM +0200, Rafael J. Wysocki wrote:

_trim_ emails!!! one of these days I'm going to write a bot to flame
your head of if there's excessive quoting.

I had a offline conversation with Daniel about this since there are
other triggers - thermal constraints and game-like apps being examples
- that might want to override the system policy. He intended
"performance" mode to mean the existing code paths and "power" mode to
mean *additional* new heuristics for energy-efficiency. The power
supply assumption is just the first one of those heuristics.

Well, so now the question is whether or not we relly want to always
go to the "power" (or "energy efficiency" if you will) mode if the system
is on battery. That arguably may not be a good thing even for energy
efficiency depending on how exactly the modes are defined.

Nobody is talking about always. But in general it seems a good enough
approach. Hell, many of the AC/BAT switches in todays power management
crap things are not always right.

Do I want it to dim the LCD further when I unplug the laptop -- mostly
no, but still it does. And the most annoying one is that it reduces the
screen blank time to something near 5 seconds or so.

Why would this be any different? If you know what you want you can turn
the knob.

So in my opinion it's too early to add things like that at this point.

Meh..


Peter,

I assume the patchset is correct for you (modulo the few comments about code), right ?

As the sysctl is some kind of ABI, I would like to make sure we reach a consensus and discuss a bit about that.

I understand Rafael and Amit could be reluctant with the power supply to be hardcoded. As mentioned Amit, we may want to switch to 'power' if the thermal framework tells us we are reaching a threshold. For example, the system is set to 'auto', we are on battery, thus the current policy is 'power', we plug the device, the current policy will switch to 'performance' but the thermal framework may want to do 'power' because of some thermal constraint.

IMO, the power supply part could be extended to take into account the thermal.

The other point is, I guess, what should do the 'power' policy ? pack tasks or not ? Override the cpuidle governor and choose the deeper idle states or not ? etc ... So in other words, how can we put a cursor between 'performance' and 'power'. Knowing on some platform one may be more efficient than another platform.

IIUC, 'performance' for you means 'max performance' and 'power' means 'max power', and a list of sysctl for each power/performance option give us the knobs to tune one or another policy ? (Each platform defining its own options)

Would this approach be ok ?

Thanks

-- Daniel







--
<http://www.linaro.org/> Linaro.org â Open source software for ARM SoCs

Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/