2023-10-25 08:04:38

by Zeng Heng

Subject: [PATCH -next] cpufreq: userspace: Keep the current frequency when set userspace policy

When switching to the userspace policy, if the current frequency is within
the range of policy's min and max values, the current frequency value
should be remained. The .limit() function is called when changing governor
or updating governor limits, so in both cases, there is no need to update
frequency if the current frequency does not exceed the threshold.

Additionally, when changing to userspace governor, the default value of
set_speed is set by reading the current frequency of the CPU, but there
is inevitable error between the frequency coming from .get_rate() interface
and the actual working frequency. Consequently, when switching to userspace
policy, keeping the current frequency can avoid unexpected changes.

Signed-off-by: Zeng Heng <[email protected]>
---
drivers/cpufreq/cpufreq_userspace.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/cpufreq/cpufreq_userspace.c b/drivers/cpufreq/cpufreq_userspace.c
index 2c42fee76daa..fe55a7bb663c 100644
--- a/drivers/cpufreq/cpufreq_userspace.c
+++ b/drivers/cpufreq/cpufreq_userspace.c
@@ -117,9 +117,7 @@ static void cpufreq_userspace_policy_limits(struct cpufreq_policy *policy)
else if (policy->min > userspace->setspeed)
__cpufreq_driver_target(policy, policy->min,
CPUFREQ_RELATION_L);
- else
- __cpufreq_driver_target(policy, userspace->setspeed,
- CPUFREQ_RELATION_L);
+ /* Otherwise, keep the current frequency. */

mutex_unlock(&userspace->mutex);
}
--
2.25.1

2023-10-25 11:18:38

by Viresh Kumar

Subject: Re: [PATCH -next] cpufreq: userspace: Keep the current frequency when set userspace policy

On 25-10-23, 16:09, Zeng Heng wrote:
> When switching to the userspace policy, if the current frequency is within
> the range of policy's min and max values, the current frequency value
> should be remained. The .limit() function is called when changing governor
> or updating governor limits, so in both cases, there is no need to update
> frequency if the current frequency does not exceed the threshold.
>
> Additionally, when changing to userspace governor, the default value of
> set_speed is set by reading the current frequency of the CPU, but there
> is inevitable error between the frequency coming from .get_rate() interface
> and the actual working frequency. Consequently, when switching to userspace
> policy, keeping the current frequency can avoid unexpected changes.
>
> Signed-off-by: Zeng Heng <[email protected]>
> ---
> drivers/cpufreq/cpufreq_userspace.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq_userspace.c b/drivers/cpufreq/cpufreq_userspace.c
> index 2c42fee76daa..fe55a7bb663c 100644
> --- a/drivers/cpufreq/cpufreq_userspace.c
> +++ b/drivers/cpufreq/cpufreq_userspace.c
> @@ -117,9 +117,7 @@ static void cpufreq_userspace_policy_limits(struct cpufreq_policy *policy)
> else if (policy->min > userspace->setspeed)
> __cpufreq_driver_target(policy, policy->min,
> CPUFREQ_RELATION_L);
> - else
> - __cpufreq_driver_target(policy, userspace->setspeed,
> - CPUFREQ_RELATION_L);
> + /* Otherwise, keep the current frequency. */
>
> mutex_unlock(&userspace->mutex);
> }

Here is some reasoning why it should be done the way it is:

commit e43e94c1eda7 ("cpufreq: Fix GOV_LIMITS handling for the userspace governor")

--
viresh

2023-10-26 02:36:32

by Zeng Heng

Subject: Re: [PATCH -next] cpufreq: userspace: Keep the current frequency when set userspace policy

在 2023/10/25 19:18, Viresh Kumar 写道:
> On 25-10-23, 16:09, Zeng Heng wrote:
>> When switching to the userspace policy, if the current frequency is within
>> the range of policy's min and max values, the current frequency value
>> should be remained. The .limit() function is called when changing governor
>> or updating governor limits, so in both cases, there is no need to update
>> frequency if the current frequency does not exceed the threshold.
>>
>> Additionally, when changing to userspace governor, the default value of
>> set_speed is set by reading the current frequency of the CPU, but there
>> is inevitable error between the frequency coming from .get_rate() interface
>> and the actual working frequency. Consequently, when switching to userspace
>> policy, keeping the current frequency can avoid unexpected changes.
>>
>> Signed-off-by: Zeng Heng <[email protected]>
>> ---
>> drivers/cpufreq/cpufreq_userspace.c | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/cpufreq/cpufreq_userspace.c b/drivers/cpufreq/cpufreq_userspace.c
>> index 2c42fee76daa..fe55a7bb663c 100644
>> --- a/drivers/cpufreq/cpufreq_userspace.c
>> +++ b/drivers/cpufreq/cpufreq_userspace.c
>> @@ -117,9 +117,7 @@ static void cpufreq_userspace_policy_limits(struct cpufreq_policy *policy)
>> else if (policy->min > userspace->setspeed)
>> __cpufreq_driver_target(policy, policy->min,
>> CPUFREQ_RELATION_L);
>> - else
>> - __cpufreq_driver_target(policy, userspace->setspeed,
>> - CPUFREQ_RELATION_L);
>> + /* Otherwise, keep the current frequency. */
>>
>> mutex_unlock(&userspace->mutex);
>> }
> Here is some reasoning why it should be done the way it is:
>
> commit e43e94c1eda7 ("cpufreq: Fix GOV_LIMITS handling for the userspace governor")


Get it, thanks for the response.

Zeng Heng