lkml.org 
[lkml]   [2015]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.


\
 
 \ /
  Last update: 2015-05-05 11:41    [W:0.455 / U:0.396 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site