linux-kernel - Re: [PATCH 01/70] cpufreq: interactive: New 'interactive' governor

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] [day] [month] [year] [list]

Message-ID: <5637A60B.7010104@linaro.org>
Date:	Mon, 2 Nov 2015 10:06:03 -0800
From:	Steve Muckle <steve.muckle@...aro.org>
To:	Peter Zijlstra <peterz@...radead.org>,
	Viresh Kumar <viresh.kumar@...aro.org>
Cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Bálint Czobor <czoborbalint@...il.com>,
	linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
	Mike Chan <mike@...roid.com>,
	Todd Poynor <toddpoynor@...gle.com>,
	Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH 01/70] cpufreq: interactive: New 'interactive' governor

On 11/02/2015 06:02 AM, Peter Zijlstra wrote:
> On Wed, Oct 28, 2015 at 08:30:42AM +0530, Viresh Kumar wrote:
>> These are the last memories I have around upstreaming this governor:
>> http://marc.info/?l=linux-kernel&m=132867057910479&w=2
>>
>> Has anything changed after that? Or we decided to go ahead with it and
>> upstream ?
> 
> Urgh, I thought we were trying to kill all the various governors by
> integrating the lot with the scheduler !?

That's the goal but it may be a while. There are major unanswered questions IMO about the viability of replacing all the governers with a single scheduler-driven implementation. Is per-entity load tracking responsive enough to drive CPU frequency? Can we replicate the functionality available and being used today with the proposed design? These aren't necessarily showstoppers but they could require considerable extra work (and debate).

If we move forward without ensuring these concerns are addressed I believe it would make things even worse than they are now since there will be people/vendors remaining behind on cpufreq governors, forward porting them if necessary, and there will be the fundamentally different sched-driven solution to support and maintain as well.

Having the interactive governor in the tree would help in the evaluation and comparison process, and also immediately address a widely used component being out of tree.
--
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/