Re: [RFC][PATCH 4/7] sched: power: Remove power capacity hints for kworker threads

[Morten Rasmussen <morten.rasmussen@arm.com>]

On Mon, Oct 14, 2013 at 04:14:25PM +0100, Arjan van de Ven wrote:
> On 10/14/2013 6:33 AM, Peter Zijlstra wrote:
> > On Fri, Oct 11, 2013 at 06:19:14PM +0100, Morten Rasmussen wrote:
> >> Removing power hints for kworker threads enables easier use of
> >> workqueues in the power driver late callback. That would otherwise
> >> lead to an endless loop unless it is prevented in the power driver.
> >
> > There's many kworker users; some of them actually consume lots of
> > cputime. Therefore how did you come to the conclusion that excepting all
> > users was the better choice of a little added complexity in the one
> > place where it actually matters?
> 
> .. and likely only for a very few architectures
> 
> x86, and I suspect modern ARM, can change frequency synchronously.
> (using an instruction or maybe two or three for ARM)

It should be possible to implement synchronous frequency changes on most
modern ARM platforms. It is a bit more than a few instructions to change
frequency though particularly for the current cpufreq drivers.

cpufreq drivers, like the one for ARM TC2, uses the clock framework to
manage clocks. clk_set_rate() is allowed to sleep which won't work if we
call it from scheduler context. The clock framework will need a look if
it doesn't provide a very fast synchronous alternative to clk_set_rate()
to change frequency and we want to use it for scheduler driven frequency
scaling.

cpufreq has pre- and post-change notifiers so the current TC2 clock driver
waits (yields) in its clk_set_rate() implementation until the change has
happened to ensure that the post-change notifier happens at the right
time. Since clk_set_rate() is allowed to sleep other tasks may be
running while waiting for the change to complete. This may be true for
other clock drivers as well.

AFAICT, there is no way to reuse the existing cpufreq drivers in a
sensible way for scheduler driven frequency scaling. It should be
possible to have very fast frequency changes on ARM but it is not the
way it is currently done.