linux-kernel - Re: [PATCH 4/4] sched: cpufreq_cfs: pelt-based cpu frequency scaling

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]

Message-ID: <20150505090042.GC21418@twins.programming.kicks-ass.net>
Date:	Tue, 5 May 2015 11:00:42 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Michael Turquette <mturquette@...aro.org>
Cc:	mingo@...nel.org, linux-kernel@...r.kernel.org,
	preeti@...ux.vnet.ibm.com, Morten.Rasmussen@....com,
	riel@...hat.com, efault@....de, nicolas.pitre@...aro.org,
	inaro-kernel@...ts.linaro.org, daniel.lezcano@...aro.org,
	patches@...aro.org, eas-dev@...ts.linaro.org,
	dietmar.eggemann@....com, vincent.guittot@...aro.org,
	amit.kucheria@...aro.org, juri.lelli@....com, rjw@...ysocki.net,
	viresh.kumar@...aro.org, ashwin.chaugule@...aro.org,
	alex.shi@...aro.org
Subject: Re: [PATCH 4/4] sched: cpufreq_cfs: pelt-based cpu frequency scaling

On Mon, May 04, 2015 at 03:10:41PM -0700, Michael Turquette wrote:
> This policy is implemented using the cpufreq governor interface for two
> main reasons:
> 
> 1) re-using the cpufreq machine drivers without using the governor
> interface is hard.
> 
> 2) using the cpufreq interface allows us to switch between the
> scheduler-driven policy and legacy cpufreq governors such as ondemand at
> run-time. This is very useful for comparative testing and tuning.

Urgh,. so I don't really like that. It adds a lot of noise to the
system. You do the irq work thing to kick the cpufreq threads which do
their little thing -- and their wakeup will influence the cfs
accounting, which in turn will start the whole thing anew.

I would really prefer you did a whole new system with directly invoked
drivers that avoid the silly dance. Your 'new' ARM systems should be
well capable of that.

You can still do 2 if you create a cpufreq off switch. You can then
either enable the sched one or the legacy cpufreq -- or both if you want
a trainwreck ;-)

As to the drivers, they're mostly fairly small and self contained, it
should not be too hard to hack them up to work without cpufreq.
--
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/