linux-kernel - Re: [PATCH v2] cpufreq/cppc: Take policy->cur into judge when set target

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 for Android: free password hash cracker in your pocket

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

Date: Thu, 30 May 2024 14:02:22 +0800
From: Riwen Lu <luriwen@...mail.com>
To: Viresh Kumar <viresh.kumar@...aro.org>,
 Ionela Voinescu <ionela.voinescu@....com>,
 Beata Michalska <beata.michalska@....com>, Hoan Tran <hotran@....com>
Cc: rafael@...nel.org, linux-pm@...r.kernel.org,
 linux-kernel@...r.kernel.org, Riwen Lu <luriwen@...inos.cn>
Subject: Re: [PATCH v2] cpufreq/cppc: Take policy->cur into judge when set
 target

在 2024/5/30 13:56, Viresh Kumar 写道:
> Cc'ing few more people.
> 
> On 30-05-24, 09:06, Riwen Lu wrote:
>> 在 2024/5/29 15:12, Viresh Kumar 写道:
>>> On 29-05-24, 14:53, Riwen Lu wrote:
>>>> Yes, you are right， I didn't think it through. In this circumstance, the
>>>> policy->cur is the highest frequency, desired_perf converted from
>>>> target_freq is the same with cpu_data->perf_ctrls.desired_perf which
>>>> shouldn't.
>>>
>>> Please investigate more and see where the real problem is.
>>>
>> The boot CPU's frequency would be configured to the highest perf when
>> powered on from S3 even though the policy governor is powersave.
>>
>> In cpufreq resume process, the booting CPU's new_freq obtained via .get() is
>> the highest frequency, while the policy->cur and
>> cpu->perf_ctrls.desired_perf are in the lowest level(powersave governor).
>> Causing the warning: "CPU frequency out of sync:", and set policy->cur to
>> new_freq. Then the governor->limits() calls cppc_cpufreq_set_target() to
>> configures the CPU frequency and returns directly because the desired_perf
>> converted from target_freq and cpu->perf_ctrls.desired_perf are the same and
>> both are the lowest_perf.
>>
>> The problem is that the cpu->perf_ctrls.desired_perf is the lowest_perf but
>> it should be the highest_perf.
>>
>> In my opinion, desired_perf and cpu->perf_ctrls.desired_perf represent the
>> target_freq and policy->cur respectively. Since target_freq and policy->cur
>> have been compared in __cpufreq_driver_target(), there's no need to compare
>> desired_perf and cpu->perf_ctrls.desired_perf again in
>> cppc_cpufreq_set_target().
>> So, maybe we can remove the following logic in cppc_cpufreq_set_target().
>> /* Return if it is exactly the same perf */
>> if (desired_perf == cpu_data->perf_ctrls.desired_perf)
>> 	return ret;
> 
> This is what I was thinking as well yesterday.
> 
OK, I'll push a V3 patch.