Re: [RFC PATCH V2 01/19] sched/power: Remove cpu idle state selection and cpu frequency tuning

[Preeti U Murthy <preeti@linux.vnet.ibm.com>]

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>