From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 722B61FF1B5 for ; Mon, 11 May 2026 04:03:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778472235; cv=none; b=cZ+GFPRdzOJZJShU7f2WlhAN/RGPXfygI87GqqSYJA8h9v11dKYIiAOmJcTlt1jiNvWN+UQb/NxAQora0a5zfxMfnDX2F4LOM+lJ0/+Z788rFigfrzpafl3DhCgMjJ0Vg3MteasUl9fO+Fp6HO5OBpkoHPuBsmTQ0iVX8npBqFA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778472235; c=relaxed/simple; bh=uAX43zJY9VCL5sRVk4Ac7LnG2HwQMuKTSjfY7y46+zs=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=nxEOed5fa22cZZEmEzmihQ9FN2K4G3xE4WkICfFF94UFVDnNtd2Ggi4Tltp87A2ceVxzSBJen1K8+Z9Y2s4FnhEaoxQ6IRA21hxWMAVlm4hRGy2iZanFAhdhZc9g7bUYroItyUNjcUk9B7ZJk0khINbKfXD76X9zhr9g4ZNhVD8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=XFjl8Bt+; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=Z8+GP5se; arc=none smtp.client-ip=205.220.168.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="XFjl8Bt+"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="Z8+GP5se" Received: from pps.filterd (m0279866.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 64AKGm7u2236722 for ; Mon, 11 May 2026 04:03:54 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= yzhbiFvZW3aBsGS+wWeIcjYiFitpSQhYtRKQkrKsr+A=; b=XFjl8Bt+WFU5otkR g2l8OvBYI60ndnLYJqsZyO0JWyUBTYqRnh7gHL7jguHZ2nwZ5lg/k9SSjFx1rMTq 9TH42bckdIAFxZslCCT0PNl/ySYUeOZNzN3cTPV2gSy15p9E2Zr+oVgDSFDepq1K q3bZcFNusGa0yNZ3oo3iOSMKk20ps9WWsI8FX8jv8TCNqO02CiJHcKGv2ZKwq4S2 r/C5rqLZR7ONytpbLu3D3ISqOXrSyCB4AXKsy/iRZP0OfX4/zKq47+iy/1N43QVQ WMcSpQtk3ycTqRWRhsDP8iSc/zxClBjCylCH9ocAnQElREwZbtJfnSMz+HTtuF93 G1ELKA== Received: from mail-pl1-f198.google.com (mail-pl1-f198.google.com [209.85.214.198]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4e1x79m4h4-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Mon, 11 May 2026 04:03:53 +0000 (GMT) Received: by mail-pl1-f198.google.com with SMTP id d9443c01a7336-2ba7662827fso35720525ad.1 for ; Sun, 10 May 2026 21:03:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1778472233; x=1779077033; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=yzhbiFvZW3aBsGS+wWeIcjYiFitpSQhYtRKQkrKsr+A=; b=Z8+GP5seEIKMgfozD0OtYQgV4zMJ7TIv2f/GanueKkup5sx0rXHF9vXEzE/JMM2Cut k0Y25O5+EnfQuOkqMb1g8HAl5m9tLeMPlJrrPT6NHikCuDpii1ZZs0Li6t/fRd5/rozt CLbt0PbaKqomKZiggSl2n08X5BaQejjrxmIx6Nne8fcs9k5YPSs1P7KkzgORl+XpxG0/ BZdNrBJ5VMskBAwot2cfvN1nupxuIDb1us3ADIE9lh7hbQed+0eyAGaNwpa8NjtgSrmV /YAndQgtVHbHS9+uf8XalkPiv0kSv4FOt4fqNzpom82ncS7Ly7h3hDGwfE136d83ukPt b2Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778472233; x=1779077033; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=yzhbiFvZW3aBsGS+wWeIcjYiFitpSQhYtRKQkrKsr+A=; b=LaxpPsBY3biv4BnraI2RGTQbGa5rovA+iulLvI3Cb/2Sqyq/LzlSJwvEtxcs1FikOO 4SRwkmuYDUkAkFQkUQjwlB1AYWbqoLWfFytyk75+HULP4GhHzUwj7EEXWgGECY1CZz4n E0HwwjdEZNTicBCl7bnjS3G2Io+MW+k+l/52dLkAJ/iP8kBbzM24O3g45F+YouwQ/Ngv uFIUXaeDfYCLADzqIqzr7ADMHll0axrX58Wwq7PTouexXJKkibgnZerrV69fTc6nSbNK O2J5M7D4c6yhuozDzrdb3r0AsHxvV56H/N65lXRH2ULbkv7d/7/UK00Xt4SaVAEfbrXt XpWQ== X-Forwarded-Encrypted: i=1; AFNElJ8+3QxwA9Nfrqj3Vg5Eo3NtKE5jb+9TWXX0diA8BWyLkH9T9uppBqgN9vc83KVmA/kMtYDSzWuB+nCXo4s=@vger.kernel.org X-Gm-Message-State: AOJu0Yz2o0v2dTHM0W0T1B/rYdoqeDmCR5/Kwgn5yx/dAkhQAghIwIQt RZV0FtnjB/lhkVLdHgRi4UgGSgXgBZXy8eqAZa/o+IrlPKjc9jcvzVffAk/BsEt6E4Raf58+B93 pAlnKzq8J2qMnrOrlsnqlEAnisMzqubLsaNgB9wDrNSIzHdKF8AICmf9dNHqOqwshm1Q= X-Gm-Gg: Acq92OEA8GlL56iNoMEg/QgRNctQ1GYx2lYUu58tAP/qPv6nukGEkbw1+9YXNvZLCKn y42xZ7UZNPUUMtO1BgF/s+iT6hZe/WT+BS1aTQeL9w2/rctalOcbtIq2zJ7Az7RDLwMV0S6Um60 C/qsxIk/pz4vZoUv/hvz+CKMbyU/j2TiyNqOMj4E9IcKGTSkpkKc9xUwcDso0qlSsJWvqn2ho3I eISTWN543UrI7Wu3LZ2NthhH/58tw42V3nyKvytlL2Hw1FUNvKhbFd60H645UWyh1T0uaR8ybtB /BxyygzUrunKHfVP+GbhAPKRDt02R+2DCAUF3t6ZD/anrmSH8c1qw2VzkSoxr7IvyZVgqo1eqYm tQsyrO01F4ZKIRWfKgJP+kkyPIAPjsIcyLjE384wPLb4WZrhkGtKBB0cmRS1E6z6f216B58e1tf 37olSFtTxBfsohhjRXlA== X-Received: by 2002:a17:903:946:b0:2b0:be79:e521 with SMTP id d9443c01a7336-2babd60bbddmr133613955ad.26.1778472232798; Sun, 10 May 2026 21:03:52 -0700 (PDT) X-Received: by 2002:a17:903:946:b0:2b0:be79:e521 with SMTP id d9443c01a7336-2babd60bbddmr133613765ad.26.1778472232260; Sun, 10 May 2026 21:03:52 -0700 (PDT) Received: from [10.133.33.247] (tpe-colo-wan-fw-bordernet.qualcomm.com. [103.229.16.4]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2baf1e365a1sm83935845ad.44.2026.05.10.21.03.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 10 May 2026 21:03:51 -0700 (PDT) Message-ID: Date: Mon, 11 May 2026 12:03:46 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] cpufreq: conservative: Fix incorrect frequency decrease due to stale target To: Viresh Kumar Cc: "zhenglifeng (A)" , rafael@kernel.org, stratosk@semaphore.gr, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, linuxarm@huawei.com, zhanjie9@hisilicon.com, lihuisong@huawei.com, yubowen8@huawei.com, zhangpengjie2@huawei.com, wangzhi12@huawei.com, linhongye@h-partners.com, zhongqiu.han@oss.qualcomm.com References: <20260421123545.1745998-1-zhenglifeng1@huawei.com> <80d32bdb-f661-44cb-b529-3d5ce2142af0@oss.qualcomm.com> Content-Language: en-US From: Zhongqiu Han In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Proofpoint-ORIG-GUID: wnUZRR6uAwBWu1X6y9YXxKBhFrcl5CHn X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNTExMDA0MSBTYWx0ZWRfXw1inzAS92Dz8 XpA9YWe3IhT10HYcHlX8efXcbm1KaFwZ6Vu9TaM7S4IHzSmFg9jHosUpPLXngxp6ldhenYPzx6q TYVAeacsfxTcY9BBQ0JF6/mAOYDQDxMZlFU8NcCoEQU2f4VzOt8MA2wHNOolksJyiScJGDeMvbk ak6fUy2xlaEBwKvRngaCV8zYCqYL9y+P0XpBk7sBkPrS+XwGYqltE29rUC7Tpqa0e1g0/FMyY+O f+A8xAmNJP5v+abcUfsCIo9w+dlXgi2nt7vRo7Q8d155AfIye1PeJ4tak5j3vK0xm8mhMJ5MjTZ zmpGMbB5LtDXwoCI3vXNgbwYeRR+7SKaVv7LzAlYdSBKy0Qo9EmwidQhp49iicOHlKveU/J4K6L EjLzPcSKJowhay7n/via2QU+pBLsYQIXF7KSv2QwcA/7JrFTM+Ipwd39XLopmNxhx+dBiHWQzOG jYJ71r4BhUQc94pKj4g== X-Proofpoint-GUID: wnUZRR6uAwBWu1X6y9YXxKBhFrcl5CHn X-Authority-Analysis: v=2.4 cv=Yvo/gYYX c=1 sm=1 tr=0 ts=6a015529 cx=c_pps a=MTSHoo12Qbhz2p7MsH1ifg==:117 a=nuhDOHQX5FNHPW3J6Bj6AA==:17 a=IkcTkHD0fZMA:10 a=NGcC8JguVDcA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=YMgV9FUhrdKAYTUUvYB2:22 a=VwQbUJbxAAAA:8 a=RqrBSwbPjokQlsvh5zYA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=GvdueXVYPmCkWapjIL-Q:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-05-11_01,2026-05-08_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 bulkscore=0 impostorscore=0 spamscore=0 clxscore=1015 phishscore=0 lowpriorityscore=0 adultscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2604200000 definitions=main-2605110041 On 5/8/2026 6:14 PM, Viresh Kumar wrote: > On 08-05-26, 14:46, Zhongqiu Han wrote: >> Nice suggestion! — I think it aligns well with the general direction of >> addressing this issue and relying more on the cpufreq core. >> >> That said, I have a concern if we drop the decrease-path early-exit >> check while keeping the existing condition: >> >> if (requested_freq > freq_step) >> >> unchanged. In that case, when the system is already at policy->min, this >> appears to introduce a governor-level oscillation, even though the >> effective hardware frequency remains unchanged: >> >> Consider the following scenario >> (policy->min = 200, freq_step = 100, hardware already at min, low load): >> >> Iteration N: >> requested_freq = 200 >> decrease path: 200 > 100 -> requested_freq = 100 >> __cpufreq_driver_target(100, LE): >> clamp -> 200, target == cur >> -> without CPUFREQ_NEED_UPDATE_LIMITS: driver not invoked >> -> with CPUFREQ_NEED_UPDATE_LIMITS: driver is still invoked >> dbs_info->requested_freq = 100 <- below min >> >> Iteration N+1: >> requested_freq = 100 >> out-of-range check: reset to policy->cur = 200 >> decrease path: 200 > 100 -> requested_freq = 100 >> dbs_info->requested_freq = 100 <- below min again >> >> This results in a repeated oscillation pattern. For drivers with >> CPUFREQ_NEED_UPDATE_LIMITS (amd-pstate, intel_cpufreq, cppc_cpufreq), >> the driver may be invoked every sampling period even though the >> effective frequency does not change. I'm happy to defer to your judgment >> on whether this is significant enough to warrant further changes. >> >> Given this, may i know would it make sense to adjust only the decrease >> path early-exit condition to use dbs_info->requested_freq (i.e. the last >> target actually requested from hardware), rather than the idle-adjusted >> local requested_freq? >> >> - if (requested_freq == policy->min) >> + if (dbs_info->requested_freq == policy->min) >> goto out; >> >> With this change, the scenario raised by Lifeng >> (dbs_info->requested_freq = 400, idle_periods = 2, low load) behaves as >> follows: >> >> Iteration 1: >> requested_freq = 400 >> idle decay: requested_freq = 200 >> if (dbs_info->requested_freq(400) == min(200)) ? NO -> continue >> 200 > 100 -> requested_freq = 100 >> __cpufreq_driver_target(100, LE): >> clamp -> 200, target(200) != cur(400) >> -> driver invoked, hardware: 400 -> 200 MHz [bug fixed] >> dbs_info->requested_freq = 100 <- one-time transient value >> >> Iteration 2: >> requested_freq = 100 >> out-of-range check: reset to policy->cur = 200 >> if (dbs_info->requested_freq(200) == min(200)) ? YES -> goto out >> >> -> Stable from iteration 2 onward, with no extra driver calls. >> >> There is a one-time transient where dbs_info->requested_freq briefly >> drops below policy->min, but this is harmless: the existing out-of-range >> check corrects it in the next iteration. A similar situation was >> discussed before [1], where the conclusion at the time was that >> __cpufreq_driver_target() already performs the necessary clamping. If it >> would be clearer or more robust to add an explicit guard >> here, this can be revisited as well at your discretion.😊 >> >> [1]https://lore.kernel.org/linux-pm/20231005105746.ikezg2buza2qwvig@vireshk-i7/ >> >> The increase-path early-exit is intentionally left unchanged, to avoid >> altering the behavior in the scenario where conservative idle decay >> would otherwise be ignored when the previous requested frequency was >> already at policy->max. > > What about this ? > > diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufreq_conservative.c > index df01d33993d8..c7ec11de9a43 100644 > --- a/drivers/cpufreq/cpufreq_conservative.c > +++ b/drivers/cpufreq/cpufreq_conservative.c > @@ -103,10 +103,6 @@ static unsigned int cs_dbs_update(struct cpufreq_policy *policy) > if (load > dbs_data->up_threshold) { > dbs_info->down_skip = 0; > > - /* if we are already at full speed then break out early */ > - if (requested_freq == policy->max) > - goto out; > - > requested_freq += freq_step; > if (requested_freq > policy->max) > requested_freq = policy->max; > @@ -124,15 +120,8 @@ static unsigned int cs_dbs_update(struct cpufreq_policy *policy) > > /* Check for frequency decrease */ > if (load < cs_tuners->down_threshold) { > - /* > - * if we cannot reduce the frequency anymore, break out early > - */ > - if (requested_freq == policy->min) > - goto out; > - > - if (requested_freq > freq_step) > - requested_freq -= freq_step; > - else > + requested_freq -= freq_step; > + if (requested_freq < policy->min) > requested_freq = policy->min; > > __cpufreq_driver_target(policy, requested_freq, > Just one small concern is that requested_freq may underflow as an unsigned value; perhaps this could be improved by: - if (requested_freq > freq_step) + if (requested_freq > policy->min + freq_step) requested_freq -= freq_step; else requested_freq = policy->min; or use min() func? Additionally, it seems that dropping the early‑exit checks also appears to be a nice side effect fix for CPUFREQ_NEED_UPDATE_LIMITS drivers when updating internal upper and lower frequency boundaries. As designed in commit 1c534352f47f ("cpufreq: Introduce CPUFREQ_NEED_UPDATE_LIMITS driver flag"), a cpufreq driver may need to update its internal frequency limits when policy min or max changes for drivers setting CPUFREQ_NEED_UPDATE_LIMITS. However, the early‑exit in cs_dbs_update() can prevent __cpufreq_driver_target() from ever being called. For example, when policy->min rises from 200 to 400 kHz while policy ->cur is already at 400 kHz, under low load: cpufreq_policy_apply_limits(): policy->min(400) > policy->cur(400) ? NO -> driver not called cs_limits(): dbs_info->requested_freq = policy->cur = 400 [next sampling period, low load] cs_dbs_update(): requested_freq = 400 if (requested_freq == policy->min) /* 400 == 400 -> true */ goto out; /* __cpufreq_driver_target() never called */ With the early‑exit removed, __cpufreq_driver_target() is called with target == policy->cur, and CPUFREQ_NEED_UPDATE_LIMITS ensures the driver is invoked to update its internal performance boundaries. -- Thx and BRs, Zhongqiu Han