linux-kernel - Re: [PATCH RFC] Revert "cpufreq: dt: Identify cpu-sharing for platforms without operating-points-v2"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 16 Jun 2016 15:57:06 +0900
From:	Alexandre Courbot <acourbot@...dia.com>
To:	Viresh Kumar <viresh.kumar@...aro.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Thierry Reding <treding@...dia.com>
CC:	<linux-pm@...r.kernel.org>, <linux-tegra@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <gnurou@...il.com>
Subject: Re: [PATCH RFC] Revert "cpufreq: dt: Identify cpu-sharing for
 platforms without operating-points-v2"

On 06/16/2016 03:35 PM, Viresh Kumar wrote:
> +Rafael
>
> On 16-06-16, 14:35, Alexandre Courbot wrote:
>> This is not an actual request for revert, but rather for comments about
>> the observed behavior since I am not really familiar with cpufreq.
>>
>> I am observing a serious performance regression on Jetson TK1 since 4.7-rc1:
>> namely, moving windows under X would become unsufferably slow, and graphical
>> performance under X in general is seriously degraded. After bisecting, I
>> found the regression to be visible since commit 1530b9963eeb ("cpufreq: dt:
>> Identify cpu-sharing for platforms without operating-points-v2")
>>
>> If I revert this commit, I noticed that the CPU frequency immediately jumps to
>> a higher frequency once I start moving windows (resulting in a smooth and
>> responsive action), whereas enabling this commit causes the CPU frequency to
>> remain low (typically 204 Mhz) in that case, resulting in CPU-bound slowness.
>>
>> What happens is that with 1530b9963eeb applied, dev_pm_opp_get_sharing_cpus()
>> returns zero causing the fallback variable to remain false, whereas without it
>> opp_v1 is set to true.
>>
>> It is not clear to me whether this is a cpufreq issue or a Tegra issue, so I am
>> posting this in the hope to get clarifications from either side.
>>
>> Thanks!
>
> Yeah, you just hit a corner case. Sorry about that :(
>
> Can you try a patch that I sent to you instead? Its subject is:
>
> [PATCH] PM / OPP: 'UNKNOWN' status of opp-table->shared

Thanks, this seems to solve the issue.

> Also I would like to know one more thing. You can hit this bug only if
> some other piece of code for your platform is creating OPP table for
> the CPUs. Which code is doing that ?

Good question. I am still educating myself about OPP - adding Thierry in 
the meantime who may have an answer.