On Mon, Sep 19, 2016 at 10:39:18PM +0300, Stratos Karafotis wrote: > On Mon, Sep 19, 2016 at 7:16 PM, Andreas Herrmann <aherrm...@suse.com> wrote: > > On Fri, Sep 16, 2016 at 09:58:42PM +0300, Stratos Karafotis wrote: > >> Hi, > >> > >> [ I 'm resending this message, because I think some recipients didn't > >> receive > >> it. ] > >> > >> On 16/09/2016 12:47 μμ, Andreas Herrmann wrote: > >> > On Wed, Sep 07, 2016 at 10:32:01AM +0530, Viresh Kumar wrote: > >> >> On 01-09-16, 15:21, Andreas Herrmann wrote: > >> >>> On Mon, Aug 29, 2016 at 11:31:53AM +0530, Viresh Kumar wrote:
---8<--- > >> > 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. > >> 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. > >> 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. > > 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