On 08/18/2014 09:09 PM, Nicolas Pitre wrote:
On Mon, 11 Aug 2014, Preeti U Murthy wrote:
As a first step towards improving the power awareness of the scheduler, this patch enables a "dumb" state where all power management is turned off. Whatever additionally we put into the kernel for cpu power management must do better than this in terms of performance as well as powersavings. This will enable us to benchmark and optimize the power aware scheduler from scratch.If we are to benchmark it against the performance of the existing design, we will get sufficiently distracted by the performance numbers and get steered away from a sane design.
I understand your goal here, but people *will* compare performance between the old and the new design anyway. So I think it would be a better approach to simply let the existing code be and create a new scheduler-based governor that can be swapped with the existing ones at run time. Eventually we'll want average users to test and compare this, and asking them to recompile a second kernel and reboot between them might get unwieldy to many people.
And by allowing both to coexist at run time, we're making sure both the old and the new code are built helping not breaking the old code. And that will also cut down on the number of #ifdefs in many places.
In other words, CONFIG_SCHED_POWER is needed to select the scheduler based governor but it shouldn't force the existing code disabled.
I don't think I understand you here. So are you proposing a runtime switch like a sysfs interface instead of a config switch? Wouldn't that be unwise given that its a complete turnaround of the behavior kernel after the switch? I agree that the first patch is a dummy patch, its meant to ensure that we have *atleast* the power efficiency that this patch brings in. Of course after that point this patch is a no-op. In fact the subsequent patches will mitigate the effect of this.
Regards Preeti U Murthy
Signed-off-by: Preeti U Murthy preeti@linux.vnet.ibm.com