[RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Viresh Kumar]

On 4 March 2014 15:57, Lukasz Majewski <l.majewski at samsung.com> wrote:
> Despite this patch set is working and applicable on top of 3.14-rc5,
> please regard it solely as a pure RFC.

Okay, I am trying to do a review here and because you have mentioned
how different it is from the earlier versions, I am trying with a fresh mind.
i.e. with zero memories of earlier discussions :)

LAB was: Legacy Application Boost ??

Probably mention that in your new threads as well, so that new readers
know the details. Also, like other governors, just name it "boost" governor.

> This patch provides support for LAB governor build on top of ondemand.
> Previous version of LAB can be found here:
> http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
>
> LAB short reminder:
>
> LAB uses information about how many cores are in "idle" state (the core
> idleness is represented as the value between 0 and 100) and the overall
> load of the system (from 0 to 100) to decide about frequency to be set.
> It is extremely useful with SoCs like Exynos4412, which can set only one
> frequency for all cores.

Probably a description of how exactly these two values come into play
would have been more interesting here for all. Always think of new followers
of your patchset and so add all interesting things about it when you resend
it.

If I remember well the logic was more or less like this:
- More idle cores means run few running cores at high frequency
- Less idle cores means don't run them at very high frequencies

Right?

What about making it as simple as:
- changing the ondemand governor only instead of adding a new governor
- Keeping the bahavior as is for all platforms not publishing boost frequencies
- If more cores are idle, enable switching to boost frequencies and take them
into consideration all the time.
- If less cores are idle, disable boost frequencies..

Lets discuss this first and then I will get into the very details of your
implementation.