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 <pre...@linux.vnet.ibm.com> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
