From nobody Thu Apr 9 08:13:33 2026 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 94A6633D6F8 for ; Tue, 10 Mar 2026 06:34:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.169 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773124492; cv=none; b=bijQX3eyFFywk+PC8oNwpxENRdW29vhHy3kw8F5/C0YYoMCYUNmJSomdnmUHtbLBCScwNi31i+vhTt5O0PrkDavwd1d6I+7Nw3NcLtXol6AR/b0fSrDDKcHYvlzecEIKQ6IWjwuPqz2QXMgvX4ceJE4EdPhLJj6eg4ChbDfkF/w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773124492; c=relaxed/simple; bh=FHDyAF9EFAwRXqOkNjanAFAqCUd0SWMg+w8X1BipR7Y=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=UO7zaBUrdVfTaCNyq6HEqX7XsEbYxea8sQaDyy+MnHTINKpQD8dbNBiJac79zU/R8tuMA+WqOUGx9AgR9lFBl8qrLesn1W4TGCDLUH7VOm/bRQoL7wGZHZC0Kbq3cRJIEiISCPFXAeofqf79te7MWVEbgI1hf4M2TIHXjeUlfmo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=frYggJxw; arc=none smtp.client-ip=209.85.214.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="frYggJxw" Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-2ad617d5b80so83898615ad.1 for ; Mon, 09 Mar 2026 23:34:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1773124491; x=1773729291; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=KsWmnYan0uzVCIt1+g+hxRLBpOd+p/q+HdKX/vP4pgs=; b=frYggJxwgG8iwaq75ovRiMkhBUB7hoOwgcmuDHkcvU1DBE/8lBKyUBcvgCY3n+/GT+ jBG1PjeOUWpDZtArQ4MQm970przpUXIDtcyklyFw15UnxeuiAWxPBkW5k/DWPms1JiBX JWuF4ytKQNGsmkHUThyEY8CuQQAyvKfNIn+lf/ltLmWKMw21AvkYOiUlAFZ8GeZr5KwO no5k1uNXm3mWcDeVlP/laQZHRnFBcNgT2PqHc/Y7e55EQAx2k2pWphaimGgrnxnHo/HS X/cP2J+t1qytmrD6LeEWSLyP4fhvBt54I3ULjr57LfemCiSUwtSm6ZKDTuy3lwrnP+YG U//g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773124491; x=1773729291; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=KsWmnYan0uzVCIt1+g+hxRLBpOd+p/q+HdKX/vP4pgs=; b=wbObEmhw/eBFxLZ8jaJm/Z1tXVJ+iWd3WtwBq1sSqKs9PqU97pRQ0OUJpH38VRpSE1 umaJrsfR7dgFCzPH6zEmrdWRK3vd6AZofg1DDkfB4h77eVofehNqv93eh4LQjbVruSEg nxSZAyuV7r9Pj9Kd1nlHA8RVx8LtThyQzBxDDa6J75kKD2XX1IVgmsQH9FBKofGe7qdZ qmdRCGSs8EAJwX03sbDuAQcF3iJiK4E4wG8LLj01qYl+A3LUxwdtDiPB9VlN/FN7WTkT ssMWUnssnx6ISW2VP0cMGjzsmhQkmaIpAqawup3SF2jvFHuALWt01YeVyzRumtXd1gMH ++9w== X-Forwarded-Encrypted: i=1; AJvYcCXutXy60MmWkRlAF7uExfIFG+qtafhhBh/EPjlgsEJoAKJciCWDd3COFUVaYVwWfqjqx2F6NdMBRAxKlR8=@vger.kernel.org X-Gm-Message-State: AOJu0Yxbl7BhKgz2JobzL9s0mFe6NHO0TW/J0q2CaGBdoo86jYtLKl0s +q2yDhAUWE7b3k9KEJS0Jwsy+nN1VNq46oe5qg6W+o06UtxrQIBzZR/jCIsjs/OWn10= X-Gm-Gg: ATEYQzzt/CT+XUia4HS3myBGubpy5a/er3SZCsqrL0K8TkH2rMmeapDE66vRb7FSz3X QSxRRem4waSuOp09CR61AWYTVNszNS8zmOhRTaX6iZDH2MhJthUMc1W32XX7PuLu3phsK7B9E3o W5dwEudlKDZCjsoIM8yzoItotAzAvIW4drc1gcBSxMcLoE/x3wEriku4ZXkHP/jfdkP2v9Mge0T 6JygwjYBo3L+kMEREEW/4yVAWM03q/cU9jBKBLh+Ri/iXESYn8VsaIQckLWKIatsJbNHUIoe4Py csThtE7Gi5zEcWFke8DcNWOBcL2BTDqydFXNMSOfmHn8kI1wek6OjbrVex8aoD6CK8qoF0W1D7V Ws+cVBQMTX994EYQ16Za8T/nPj2lmoN4LE+UiyRzGuQT3XU+u5MyOiqPCx1Yu23X1Amo5wd32st q0b7Og17vyrck2IdkJUXw8t1rl X-Received: by 2002:a17:902:db09:b0:2ae:5a58:ec35 with SMTP id d9443c01a7336-2ae82532c8emr157306005ad.53.1773124490693; Mon, 09 Mar 2026 23:34:50 -0700 (PDT) Received: from localhost ([122.172.81.200]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ae83e9c965sm141258485ad.32.2026.03.09.23.34.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Mar 2026 23:34:49 -0700 (PDT) From: Viresh Kumar To: "Rafael J. Wysocki" , Viresh Kumar Cc: linux-pm@vger.kernel.org, Vincent Guittot , Lifeng Zheng , linux-kernel@vger.kernel.org Subject: [PATCH] cpufreq: conservative: Drop cached requested_freq Date: Tue, 10 Mar 2026 12:04:42 +0530 Message-Id: X-Mailer: git-send-email 2.31.1.272.g89b43f80a514 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" A recently reported issue highlighted that the cached requested_freq is not guaranteed to stay in sync with policy->cur. If the platform changes the actual CPU frequency after the governor sets one (e.g. due to platform-specific frequency scaling) and a re-sync occurs later, policy->cur may diverge from requested_freq. This can lead to incorrect behavior in the conservative governor. For example, the governor may assume the CPU is already running at the maximum frequency and skip further increases even though there is still headroom. Avoid this by dropping the cached requested_freq and using policy->cur directly. Reported-by: Lifeng Zheng Link: https://lore.kernel.org/all/20260210115458.3493646-1-zhenglifeng1@hua= wei.com/ Signed-off-by: Viresh Kumar Tested-by: Lifeng Zheng --- Lifeng Zheng, can you please give this a try and provide your Tested-by as = well ? drivers/cpufreq/cpufreq_conservative.c | 16 +--------------- 1 file changed, 1 insertion(+), 15 deletions(-) diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufr= eq_conservative.c index e0e847764511..c69577e4f941 100644 --- a/drivers/cpufreq/cpufreq_conservative.c +++ b/drivers/cpufreq/cpufreq_conservative.c @@ -14,7 +14,6 @@ struct cs_policy_dbs_info { struct policy_dbs_info policy_dbs; unsigned int down_skip; - unsigned int requested_freq; }; =20 static inline struct cs_policy_dbs_info *to_dbs_info(struct policy_dbs_inf= o *policy_dbs) @@ -59,10 +58,10 @@ static unsigned int cs_dbs_update(struct cpufreq_policy= *policy) { struct policy_dbs_info *policy_dbs =3D policy->governor_data; struct cs_policy_dbs_info *dbs_info =3D to_dbs_info(policy_dbs); - unsigned int requested_freq =3D dbs_info->requested_freq; struct dbs_data *dbs_data =3D policy_dbs->dbs_data; struct cs_dbs_tuners *cs_tuners =3D dbs_data->tuners; unsigned int load =3D dbs_update(policy); + unsigned int requested_freq =3D policy->cur; unsigned int freq_step; =20 /* @@ -72,16 +71,6 @@ static unsigned int cs_dbs_update(struct cpufreq_policy = *policy) if (cs_tuners->freq_step =3D=3D 0) goto out; =20 - /* - * If requested_freq is out of range, it is likely that the limits - * changed in the meantime, so fall back to current frequency in that - * case. - */ - if (requested_freq > policy->max || requested_freq < policy->min) { - requested_freq =3D policy->cur; - dbs_info->requested_freq =3D requested_freq; - } - freq_step =3D get_freq_step(cs_tuners, policy); =20 /* @@ -113,7 +102,6 @@ static unsigned int cs_dbs_update(struct cpufreq_policy= *policy) =20 __cpufreq_driver_target(policy, requested_freq, CPUFREQ_RELATION_HE); - dbs_info->requested_freq =3D requested_freq; goto out; } =20 @@ -137,7 +125,6 @@ static unsigned int cs_dbs_update(struct cpufreq_policy= *policy) =20 __cpufreq_driver_target(policy, requested_freq, CPUFREQ_RELATION_LE); - dbs_info->requested_freq =3D requested_freq; } =20 out: @@ -310,7 +297,6 @@ static void cs_start(struct cpufreq_policy *policy) struct cs_policy_dbs_info *dbs_info =3D to_dbs_info(policy->governor_data= ); =20 dbs_info->down_skip =3D 0; - dbs_info->requested_freq =3D policy->cur; } =20 static struct dbs_governor cs_governor =3D { --=20 2.31.1.272.g89b43f80a514