* [PATCH 0/2] cpufreq: CPPC: Avoid cur frequency modification on governor start @ 2025-08-23 0:17 Prashant Malani 2025-08-23 0:17 ` [PATCH 1/2] cpufreq: Add driver flag to avoid initial frequency verification Prashant Malani 2025-08-23 0:17 ` [PATCH 2/2] cpufreq: CPPC: Don't verify cur frequency on governor start Prashant Malani 0 siblings, 2 replies; 5+ messages in thread From: Prashant Malani @ 2025-08-23 0:17 UTC (permalink / raw) To: open list, open list:CPU FREQUENCY SCALING FRAMEWORK, Rafael J. Wysocki, Viresh Kumar Cc: Beata Michalska, Prashant Malani This is a short series that handles an issue where, on CPPC-based systems, the cpu frequency was getting unintentionally set to the wrong value on governor start ( and overriding the existing policy frequency) because of unreliable AMU/CPPC counters. This adds a governor flag that avoids the check against the CPPC AMU-based frequency when the governor starts. It then modifies the CPPC CPU freq driver to opt in to using this flag. Prashant Malani (2): cpufreq: Add driver flag to avoid initial frequency verification cpufreq: CPPC: Don't verify cur frequency on governor start drivers/cpufreq/cppc_cpufreq.c | 3 ++- drivers/cpufreq/cpufreq.c | 3 ++- include/linux/cpufreq.h | 10 ++++++++++ 3 files changed, 14 insertions(+), 2 deletions(-) -- 2.51.0.rc2.233.g662b1ed5c5-goog ^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH 1/2] cpufreq: Add driver flag to avoid initial frequency verification 2025-08-23 0:17 [PATCH 0/2] cpufreq: CPPC: Avoid cur frequency modification on governor start Prashant Malani @ 2025-08-23 0:17 ` Prashant Malani 2025-08-25 4:56 ` Viresh Kumar 2025-08-23 0:17 ` [PATCH 2/2] cpufreq: CPPC: Don't verify cur frequency on governor start Prashant Malani 1 sibling, 1 reply; 5+ messages in thread From: Prashant Malani @ 2025-08-23 0:17 UTC (permalink / raw) To: open list, open list:CPU FREQUENCY SCALING FRAMEWORK, Rafael J. Wysocki, Viresh Kumar Cc: Beata Michalska, Prashant Malani Some cpufreq drivers have a get() function which can return an unreliable frequency. This can cause issues when switching governors. For instance, a CPU would be on performance governor and have it's frequency (and policy->cur) set to max. When the governor is switched to userspace, the policy->cur is re-used, but it is checked against the frequency returned by the driver's get() function. If it's different, the frequency will get set to the new (incorrect) value. To avoid this, add a flag that avoids this verify step on governor start if the cpufreq driver opts in to it. Since there are no users of this flag, no functional changes are introduced here. Cc: Beata Michalska <beata.michalska@arm.com> Signed-off-by: Prashant Malani <pmalani@google.com> --- drivers/cpufreq/cpufreq.c | 3 ++- include/linux/cpufreq.h | 10 ++++++++++ 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index b8937737d096..72e6552a40ea 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -2482,7 +2482,8 @@ int cpufreq_start_governor(struct cpufreq_policy *policy) pr_debug("%s: for CPU %u\n", __func__, policy->cpu); - cpufreq_verify_current_freq(policy, false); + if (!(cpufreq_driver->flags & CPUFREQ_DONT_VERIFY_FREQ_ON_GOVERNOR_START)) + cpufreq_verify_current_freq(policy, false); if (policy->governor->start) { ret = policy->governor->start(policy); diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h index 95f3807c8c55..1ebc12fcc905 100644 --- a/include/linux/cpufreq.h +++ b/include/linux/cpufreq.h @@ -474,6 +474,16 @@ struct cpufreq_driver { */ #define CPUFREQ_NO_AUTO_DYNAMIC_SWITCHING BIT(6) +/* + * Set by drivers which want cpufreq core to avoid verifying that the current + * frequency of the policy matches the frequency returned by the driver's get() + * function. The get() function on certain drivers returns unreliable values, + * and this can result in the frequency (and consequently system performance) + * being reduced even though the governor didn't want the frequencies to be + * reduced. + */ +#define CPUFREQ_DONT_VERIFY_FREQ_ON_GOVERNOR_START BIT(7) + int cpufreq_register_driver(struct cpufreq_driver *driver_data); void cpufreq_unregister_driver(struct cpufreq_driver *driver_data); -- 2.51.0.rc2.233.g662b1ed5c5-goog ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH 1/2] cpufreq: Add driver flag to avoid initial frequency verification 2025-08-23 0:17 ` [PATCH 1/2] cpufreq: Add driver flag to avoid initial frequency verification Prashant Malani @ 2025-08-25 4:56 ` Viresh Kumar 2025-08-25 7:49 ` Beata Michalska 0 siblings, 1 reply; 5+ messages in thread From: Viresh Kumar @ 2025-08-25 4:56 UTC (permalink / raw) To: Prashant Malani Cc: open list, open list:CPU FREQUENCY SCALING FRAMEWORK, Rafael J. Wysocki, Beata Michalska On 23-08-25, 00:17, Prashant Malani wrote: > Some cpufreq drivers have a get() function which can return an unreliable > frequency. This can cause issues when switching governors. For instance, > a CPU would be on performance governor and have it's frequency (and > policy->cur) set to max. When the governor is switched to userspace, the > policy->cur is re-used, but it is checked against the frequency returned > by the driver's get() function. If it's different, the frequency will > get set to the new (incorrect) value. > > To avoid this, add a flag that avoids this verify step on governor start > if the cpufreq driver opts in to it. > > Since there are no users of this flag, no functional changes are > introduced here. > > Cc: Beata Michalska <beata.michalska@arm.com> > Signed-off-by: Prashant Malani <pmalani@google.com> > --- > drivers/cpufreq/cpufreq.c | 3 ++- > include/linux/cpufreq.h | 10 ++++++++++ > 2 files changed, 12 insertions(+), 1 deletion(-) > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > index b8937737d096..72e6552a40ea 100644 > --- a/drivers/cpufreq/cpufreq.c > +++ b/drivers/cpufreq/cpufreq.c > @@ -2482,7 +2482,8 @@ int cpufreq_start_governor(struct cpufreq_policy *policy) > > pr_debug("%s: for CPU %u\n", __func__, policy->cpu); > > - cpufreq_verify_current_freq(policy, false); > + if (!(cpufreq_driver->flags & CPUFREQ_DONT_VERIFY_FREQ_ON_GOVERNOR_START)) > + cpufreq_verify_current_freq(policy, false); I don't think it is okay to do this to hide a driver's failure to return the right frequency. What about all the other places where get() is still used ? Won't that cause similar issues elsewhere ? The driver must be fixed for this, not the core. The core is doing the right thing here, asking the driver to return the current frequency. If the driver is unsure, it can just return the current frequency from policy->cur instead. -- viresh ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 1/2] cpufreq: Add driver flag to avoid initial frequency verification 2025-08-25 4:56 ` Viresh Kumar @ 2025-08-25 7:49 ` Beata Michalska 0 siblings, 0 replies; 5+ messages in thread From: Beata Michalska @ 2025-08-25 7:49 UTC (permalink / raw) To: Viresh Kumar Cc: Prashant Malani, open list, open list:CPU FREQUENCY SCALING FRAMEWORK, Rafael J. Wysocki On Mon, Aug 25, 2025 at 10:26:41AM +0530, Viresh Kumar wrote: > On 23-08-25, 00:17, Prashant Malani wrote: > > Some cpufreq drivers have a get() function which can return an unreliable > > frequency. This can cause issues when switching governors. For instance, > > a CPU would be on performance governor and have it's frequency (and > > policy->cur) set to max. When the governor is switched to userspace, the > > policy->cur is re-used, but it is checked against the frequency returned > > by the driver's get() function. If it's different, the frequency will > > get set to the new (incorrect) value. > > > > To avoid this, add a flag that avoids this verify step on governor start > > if the cpufreq driver opts in to it. > > > > Since there are no users of this flag, no functional changes are > > introduced here. > > > > Cc: Beata Michalska <beata.michalska@arm.com> > > Signed-off-by: Prashant Malani <pmalani@google.com> > > --- > > drivers/cpufreq/cpufreq.c | 3 ++- > > include/linux/cpufreq.h | 10 ++++++++++ > > 2 files changed, 12 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > > index b8937737d096..72e6552a40ea 100644 > > --- a/drivers/cpufreq/cpufreq.c > > +++ b/drivers/cpufreq/cpufreq.c > > @@ -2482,7 +2482,8 @@ int cpufreq_start_governor(struct cpufreq_policy *policy) > > > > pr_debug("%s: for CPU %u\n", __func__, policy->cpu); > > > > - cpufreq_verify_current_freq(policy, false); > > + if (!(cpufreq_driver->flags & CPUFREQ_DONT_VERIFY_FREQ_ON_GOVERNOR_START)) > > + cpufreq_verify_current_freq(policy, false); > > I don't think it is okay to do this to hide a driver's failure to > return the right frequency. What about all the other places where > get() is still used ? Won't that cause similar issues elsewhere ? > > The driver must be fixed for this, not the core. The core is doing the Agreed. --- BR Beata > right thing here, asking the driver to return the current frequency. > If the driver is unsure, it can just return the current frequency from > policy->cur instead. > > -- > viresh ^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH 2/2] cpufreq: CPPC: Don't verify cur frequency on governor start 2025-08-23 0:17 [PATCH 0/2] cpufreq: CPPC: Avoid cur frequency modification on governor start Prashant Malani 2025-08-23 0:17 ` [PATCH 1/2] cpufreq: Add driver flag to avoid initial frequency verification Prashant Malani @ 2025-08-23 0:17 ` Prashant Malani 1 sibling, 0 replies; 5+ messages in thread From: Prashant Malani @ 2025-08-23 0:17 UTC (permalink / raw) To: open list, open list:CPU FREQUENCY SCALING FRAMEWORK, Rafael J. Wysocki, Viresh Kumar Cc: Beata Michalska, Prashant Malani Opt in to not verifying the policy's current frequency when the governor starts. CPPC's get() function is known to return unreliable values, so checking against that can mean the frequency gets set to the unreliable value even though the governor (and user) didn't intend to do so. That in turn causes unexpected performance drops. Cc: Beata Michalska <beata.michalska@arm.com> Signed-off-by: Prashant Malani <pmalani@google.com> --- drivers/cpufreq/cppc_cpufreq.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c index 4a17162a392d..7fd6c03bb726 100644 --- a/drivers/cpufreq/cppc_cpufreq.c +++ b/drivers/cpufreq/cppc_cpufreq.c @@ -910,7 +910,8 @@ static struct freq_attr *cppc_cpufreq_attr[] = { }; static struct cpufreq_driver cppc_cpufreq_driver = { - .flags = CPUFREQ_CONST_LOOPS | CPUFREQ_NEED_UPDATE_LIMITS, + .flags = CPUFREQ_CONST_LOOPS | CPUFREQ_NEED_UPDATE_LIMITS | + CPUFREQ_DONT_VERIFY_FREQ_ON_GOVERNOR_START, .verify = cppc_verify_policy, .target = cppc_cpufreq_set_target, .get = cppc_cpufreq_get_rate, -- 2.51.0.rc2.233.g662b1ed5c5-goog ^ permalink raw reply related [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-08-25 7:49 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-08-23 0:17 [PATCH 0/2] cpufreq: CPPC: Avoid cur frequency modification on governor start Prashant Malani 2025-08-23 0:17 ` [PATCH 1/2] cpufreq: Add driver flag to avoid initial frequency verification Prashant Malani 2025-08-25 4:56 ` Viresh Kumar 2025-08-25 7:49 ` Beata Michalska 2025-08-23 0:17 ` [PATCH 2/2] cpufreq: CPPC: Don't verify cur frequency on governor start Prashant Malani
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).