linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lukasz Luba <lukasz.luba@arm.com>
To: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org,
	linux-arm-msm@vger.kernel.org, steev@kali.org,
	lukasz.luba@arm.com, sudeep.holla@arm.com, will@kernel.org,
	catalin.marinas@arm.com, linux@armlinux.org.uk,
	gregkh@linuxfoundation.org, rafael@kernel.org,
	viresh.kumar@linaro.org, amitk@kernel.org,
	daniel.lezcano@linaro.org, amit.kachhap@gmail.com,
	thara.gopinath@linaro.org, bjorn.andersson@linaro.org,
	agross@kernel.org
Subject: [PATCH v4 4/5] cpufreq: qcom-cpufreq-hw: Use new thermal pressure update function
Date: Tue,  9 Nov 2021 19:57:13 +0000	[thread overview]
Message-ID: <20211109195714.7750-5-lukasz.luba@arm.com> (raw)
In-Reply-To: <20211109195714.7750-1-lukasz.luba@arm.com>

Thermal pressure provides a new API, which allows to use CPU frequency
as an argument. That removes the need of local conversion to capacity.
Use this new API and remove old local conversion code.

The new arch_update_thermal_pressure() also accepts boost frequencies,
which solves issue in the driver code with wrong reduced capacity
calculation. The reduced capacity was calculated wrongly due to
'policy->cpuinfo.max_freq' used as a divider. The value present there was
actually the boost frequency. Thus, even a normal maximum frequency value
which corresponds to max CPU capacity (arch_scale_cpu_capacity(cpu_id))
is not able to remove the capping.

The second side effect which is solved is that the reduced frequency wasn't
properly translated into the right reduced capacity,
e.g.
boost frequency = 3000MHz (stored in policy->cpuinfo.max_freq)
max normal frequency = 2500MHz (which is 1024 capacity)
2nd highest frequency = 2000MHz (which translates to 819 capacity)

Then in a scenario when the 'throttled_freq' max allowed frequency was
2000MHz the driver translated it into 682 capacity:
capacity = 1024 * 2000 / 3000 = 682
Then set the pressure value bigger than actually applied by the HW:
max_capacity - capacity => 1024 - 682 = 342 (<- thermal pressure)
Which was causing higher throttling and misleading task scheduler
about available CPU capacity.
A proper calculation in such case should be:
capacity = 1024 * 2000 / 2500 = 819
1024 - 819 = 205 (<- thermal pressure)

This patch relies on the new arch_update_thermal_pressure() handling
correctly such use case (with boost frequencies).

Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
---
 drivers/cpufreq/qcom-cpufreq-hw.c | 15 +++------------
 1 file changed, 3 insertions(+), 12 deletions(-)

diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
index 0138b2ec406d..248135e5087e 100644
--- a/drivers/cpufreq/qcom-cpufreq-hw.c
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -275,10 +275,10 @@ static unsigned int qcom_lmh_get_throttle_freq(struct qcom_cpufreq_data *data)
 
 static void qcom_lmh_dcvs_notify(struct qcom_cpufreq_data *data)
 {
-	unsigned long max_capacity, capacity, freq_hz, throttled_freq;
 	struct cpufreq_policy *policy = data->policy;
 	int cpu = cpumask_first(policy->cpus);
 	struct device *dev = get_cpu_device(cpu);
+	unsigned long freq_hz, throttled_freq;
 	struct dev_pm_opp *opp;
 	unsigned int freq;
 
@@ -295,17 +295,8 @@ static void qcom_lmh_dcvs_notify(struct qcom_cpufreq_data *data)
 
 	throttled_freq = freq_hz / HZ_PER_KHZ;
 
-	/* Update thermal pressure */
-
-	max_capacity = arch_scale_cpu_capacity(cpu);
-	capacity = mult_frac(max_capacity, throttled_freq, policy->cpuinfo.max_freq);
-
-	/* Don't pass boost capacity to scheduler */
-	if (capacity > max_capacity)
-		capacity = max_capacity;
-
-	arch_set_thermal_pressure(policy->related_cpus,
-				  max_capacity - capacity);
+	/* Update thermal pressure (the boost frequencies are accepted) */
+	arch_update_thermal_pressure(policy->related_cpus, throttled_freq);
 
 	/*
 	 * In the unlikely case policy is unregistered do not enable
-- 
2.17.1


  parent reply	other threads:[~2021-11-09 19:57 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-09 19:57 [PATCH v4 0/5] Refactor thermal pressure update to avoid code duplication Lukasz Luba
2021-11-09 19:57 ` [PATCH v4 1/5] arch_topology: Introduce thermal pressure update function Lukasz Luba
2021-11-16 23:39   ` Thara Gopinath
2021-11-23  9:09     ` Lukasz Luba
2021-11-09 19:57 ` [PATCH v4 2/5] thermal: cpufreq_cooling: Use new " Lukasz Luba
2021-11-09 19:57 ` [PATCH v4 3/5] cpufreq: qcom-cpufreq-hw: Update offline CPUs per-cpu thermal pressure Lukasz Luba
2021-11-09 19:57 ` Lukasz Luba [this message]
2021-11-15 20:57   ` [PATCH v4 4/5] cpufreq: qcom-cpufreq-hw: Use new thermal pressure update function Thara Gopinath
2021-11-15 23:39     ` Thara Gopinath
2021-11-16  8:28       ` Lukasz Luba
2021-11-16  8:30     ` Lukasz Luba
2021-11-09 19:57 ` [PATCH v4 5/5] arch_topology: Remove unused topology_set_thermal_pressure() and related Lukasz Luba
2021-11-11  3:15 ` [PATCH v4 0/5] Refactor thermal pressure update to avoid code duplication Viresh Kumar
2021-11-23  9:11   ` Lukasz Luba
2021-11-23  9:45 ` Viresh Kumar
2021-11-23  9:46   ` Lukasz Luba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211109195714.7750-5-lukasz.luba@arm.com \
    --to=lukasz.luba@arm.com \
    --cc=agross@kernel.org \
    --cc=amit.kachhap@gmail.com \
    --cc=amitk@kernel.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=rafael@kernel.org \
    --cc=steev@kali.org \
    --cc=sudeep.holla@arm.com \
    --cc=thara.gopinath@linaro.org \
    --cc=viresh.kumar@linaro.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).