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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 18 Aug 2014 22:56:57 +0530
From:	Preeti U Murthy <preeti@...ux.vnet.ibm.com>
To:	Nicolas Pitre <nicolas.pitre@...aro.org>
CC:	alex.shi@...el.com, vincent.guittot@...aro.org,
	peterz@...radead.org, pjt@...gle.com, efault@....de,
	rjw@...ysocki.net, morten.rasmussen@....com,
	svaidy@...ux.vnet.ibm.com, arjan@...ux.intel.com, mingo@...nel.org,
	len.brown@...el.com, yuyang.du@...el.com,
	linaro-kernel@...ts.linaro.org, daniel.lezcano@...aro.org,
	corbet@....net, catalin.marinas@....com, markgross@...gnar.org,
	sundar.iyer@...el.com, linux-kernel@...r.kernel.org,
	dietmar.eggemann@....com, Lorenzo.Pieralisi@....com,
	mike.turquette@...aro.org, akpm@...ux-foundation.org,
	paulmck@...ux.vnet.ibm.com, tglx@...utronix.de
Subject: Re: [RFC PATCH V2 01/19] sched/power: Remove cpu idle state selection
 and cpu frequency tuning

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@...ux.vnet.ibm.com>

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