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

From: Preeti U Murthy
Date: Mon Aug 18 2014 - 13:27:23 EST


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@xxxxxxxxxxxxxxxxxx>

--
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/