[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230826095743.1138495-1-liaochang1@huawei.com>
Date: Sat, 26 Aug 2023 09:57:43 +0000
From: Liao Chang <liaochang1@...wei.com>
To: <rafael@...nel.org>, <viresh.kumar@...aro.org>
CC: <linux-pm@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: [PATCH] cpufreq: pcc: Fix the potentinal scheduling delays in target_index()
pcc_cpufreq_target():
cpufreq_freq_transition_begin();
spin_lock(&pcc_lock);
[critical section]
cpufreq_freq_transition_end();
spin_unlock(&pcc_lock);
Above code has a performance issue, consider that Task0 executes
'cpufreq_freq_transition_end()' to wake Task1 and preempted imediatedly
without releasing 'pcc_lock', then Task1 needs to wait for Task0 to
release 'pcc_lock'. In the worst case, this locking order can result in
Task1 wasting two scheduling rounds before it can enter the critical
section.
Signed-off-by: Liao Chang <liaochang1@...wei.com>
---
drivers/cpufreq/pcc-cpufreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/pcc-cpufreq.c b/drivers/cpufreq/pcc-cpufreq.c
index 73efbcf5513b..9d732a00e2a5 100644
--- a/drivers/cpufreq/pcc-cpufreq.c
+++ b/drivers/cpufreq/pcc-cpufreq.c
@@ -232,8 +232,8 @@ static int pcc_cpufreq_target(struct cpufreq_policy *policy,
status = ioread16(&pcch_hdr->status);
iowrite16(0, &pcch_hdr->status);
- cpufreq_freq_transition_end(policy, &freqs, status != CMD_COMPLETE);
spin_unlock(&pcc_lock);
+ cpufreq_freq_transition_end(policy, &freqs, status != CMD_COMPLETE);
if (status != CMD_COMPLETE) {
pr_debug("target: FAILED for cpu %d, with status: 0x%x\n",
--
2.34.1
Powered by blists - more mailing lists