Messages in this thread | | | Date | Tue, 5 May 2015 11:00:42 +0200 | From | Peter Zijlstra <> | 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.
| |