On Mon, Sep 19, 2016 at 10:39:18PM +0300, Stratos Karafotis wrote:

On Mon, Sep 19, 2016 at 7:16 PM, Andreas Herrmann [off-list ref] wrote:

quoted

On Fri, Sep 16, 2016 at 09:58:42PM +0300, Stratos Karafotis wrote:

quoted

Hi,

[ I 'm resending this message, because I think some recipients didn't receive
it. ]

On 16/09/2016 12:47 μμ, Andreas Herrmann wrote:

quoted

On Wed, Sep 07, 2016 at 10:32:01AM +0530, Viresh Kumar wrote:

quoted

On 01-09-16, 15:21, Andreas Herrmann wrote:

quoted

On Mon, Aug 29, 2016 at 11:31:53AM +0530, Viresh Kumar wrote:

  ---8<---

quoted

quoted

quoted

It seems that the decision how to best map load values to target
frequencies is kind of hardware specific.

Maybe a solution to this is that the cpufreq driver should be able to
provide a mapping function to overwrite the current default
calculation.

FYI, I've created new patches to address the issue.

First one will be to introduce a map_load_to_freq function. The
default being what commit 6393d6 introduced (no deadband).  Second
patch will than introduce a specific function for pcc-cpufreq to fall
back to what was used before commit 6393d6.

I just want to assemble gathered performance data and I am planning to
send those patches tomorrow.

quoted

quoted

I'm not familiar with ppc-cpufreq drive but maybe patch 6393d6 just
uncovered an "issue" that was already existed but only on higher loads.

Because, with or without patch 6393d6, if the specific CPU doesn't
use a frequency table, there will many frequency transitions in
higher loads too. I believe, though, that the side effect it's smaller
in higher frequencies because CPUs tend to work on lowest and highest
frequencies.

Might be. I didn't test this specifically.

Hopefully I'll also find time to gather some ftrace data wrt this.

quoted

quoted

What about a patch in ppc-cpufreq driver that permits frequency
changes only in specific steps and not in arbitrary values?

Which steps would you use? What scheme would be universal usable for
all affected system using this driver?

Just an idea. I would split the frequency range (max_freq - min_freq)
into ~10 steps. But I'm not familiar with the affected systems and
of course I can't prove this is an ideal approach.

I've modified the pcc-cpufreq specific map_load_to_freq function to do
just that (map load values to 10 discrete frequency values) instead of
falling back to the deadband (pre-commit-6393d6-version).

Unfortunately this resulted in lower performance compared to
pre-commit-6393d6-version.

quoted

I had played with an approach to only make use of min_freq and
max_freq which eventually didn't result in better performance
in comparison to code before commit 6393d6.

Regards,
Stratos

Regards,

Andreas