Date: Tue, 5 May 2015 11:00:42 +0200
From: Peter Zijlstra <peterz@infradead.org>
To: Michael Turquette <mturquette@linaro.org>
Cc: mingo@kernel.org, linux-kernel@vger.kernel.org, preeti@linux.vnet.ibm.com,
        Morten.Rasmussen@arm.com, riel@redhat.com, efault@gmx.de,
        nicolas.pitre@linaro.org, inaro-kernel@lists.linaro.org,
        daniel.lezcano@linaro.org, patches@linaro.org,
        eas-dev@lists.linaro.org, dietmar.eggemann@arm.com,
        vincent.guittot@linaro.org, amit.kucheria@linaro.org,
        juri.lelli@arm.com, rjw@rjwysocki.net, viresh.kumar@linaro.org,
        ashwin.chaugule@linaro.org, alex.shi@linaro.org
Subject: Re: [PATCH 4/4] sched: cpufreq_cfs: pelt-based cpu frequency scaling
Message-ID: <20150505090042.GC21418@twins.programming.kicks-ass.net>
References: <1430777441-15087-1-git-send-email-mturquette@linaro.org>
 <1430777441-15087-5-git-send-email-mturquette@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1430777441-15087-5-git-send-email-mturquette@linaro.org>
User-Agent: Mutt/1.5.21 (2012-12-30)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1422
Lines: 31

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/