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 17201355F22 for ; Fri, 8 May 2026 06:47:07 +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=1778222833; cv=none; b=oGUtUAQzEypuJSUkqIusm4mG6qg2GMubB7XsyK24p9t4rmxVxNd/G9VZGXCgxEe6hMKHvteox4IiESFSwJaVDvS8XXnNagvcWMyPBfTv5wflNIc5jaSzRLhZ/DuakTbIL9zlcZLC0stDv+Paoia+fHMO7Lzb4c4DFMnLiTdZdaA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778222833; c=relaxed/simple; bh=qw3oZQK5F3aNCaZjcgdboq0+FguF5W83K4D+0fgvxE8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=k2dyta0LpOXl6fIL+a/3IPlUGLQfy95E3yfpqtWOy9tMcUvOBV/fAZbTJkcG/vw+htRu6Sy3onOvTufHSN+XoeMa6y99GccZ5ynHoPkJc9dgmsQTxOaGsMAJzATvtluMN/zVrjQwbMqC0e7NJMhm2AGafskuSOLpXi3z7zuRN3s= 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=c8FJqp80; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=NCwssyGK; 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="c8FJqp80"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="NCwssyGK" Received: from pps.filterd (m0279867.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 6485iI9o2777671 for ; Fri, 8 May 2026 06:47:05 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= hgYa7VVGLVSTLTDj6wGtEsacvpNZkrN6GG3DxUuSAl0=; b=c8FJqp807XIfXAuK RLX0OBEOCn+NI4VPJX3DinifOkJG5cWFajT3oAIArU4FN0N62Hyadbvvmi8R3uzd FFMtRF22HFI6wfPdtlBg09xwMNdvt+httVgHQb/Z/jnIGBOTiBlP1LJtCOaM0LOG wEOvgilHgfgNwQDi3S2N/x5MTOidnnS517nnDzhbRxtJl2o37svzw1nj4N3u2JCz f6tpC6KOtuUh2Wv5Kx4j5+vCrjRJvXZjOxHBxBp5D+oVgL4Y2xd0Vmun0X1sNBBW tQhj8V45eDCtNEj/oocr1HUV2q2EK/oaSR+BcwcyN9+ksOaWxI/iLzmkIhJF8ii/ +S65BA== Received: from mail-pl1-f197.google.com (mail-pl1-f197.google.com [209.85.214.197]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4e1285hrkj-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Fri, 08 May 2026 06:47:05 +0000 (GMT) Received: by mail-pl1-f197.google.com with SMTP id d9443c01a7336-2b4654f9bb6so18972035ad.2 for ; Thu, 07 May 2026 23:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1778222824; x=1778827624; 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=hgYa7VVGLVSTLTDj6wGtEsacvpNZkrN6GG3DxUuSAl0=; b=NCwssyGK+NDHAo4KMYiWvL4WMnd6ZcO6XL2LssfRtZ/gLcCqIH9Ni/M2rh535xY1kQ 8RDlxHaRGmL91XftNHwwbZuO1yRTTSAd/bg0KuKQclt9ZaZ8bc6Ai3z/VeePB/n6ST1t wNICEFDlaH3PS+btEatOldNcB3vlxyUxBx8RTgG5zE7EUwvE877ucYpCHmCpOHW5T9dc ZqE+NwM3w4bgFS462OX3RrgBtnqkdNrFKtfm0ZrkT49byz8dfZuy1DB5qd2ylLuG1zjO dQzMtQd5Qq4PtRLDAG9qQkO6r2xb6Lwqymj8A8xrtLMO6BAwTSdj1z90z8yyVxdDbd5n Av/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778222824; x=1778827624; 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=hgYa7VVGLVSTLTDj6wGtEsacvpNZkrN6GG3DxUuSAl0=; b=hZxfWEJTqXa+L8ftCsjggwM413rRtKDIl11QC34SZ64KDsttFzQNeKGv261aEnWdPz qS+hjAAxRUyndawijEXQG8WloH4iKyBMb2NeEnLOMirPf0fF01wPudfD/fdyWAdJOYRq Gq5+TPrgq6qnofCbCwDjKpY0Fu57rVLEFAcGo2gzpNRxfBZeG0kBzUh/WpgGRmg4yMG0 hsQCp1f4ZKOAKN5dyMitQMv0zFZttfl2dMkbTVGyV5MEucdTmIUZ2aBK+2OqokdijQv+ k0Oy/JT/FaI0m2ITJzRbPYZ7RJPBA/C5xJmHEPtyOpo77maYNfJyoSb8q8xsGwoPBWna rGKg== X-Forwarded-Encrypted: i=1; AFNElJ9CkEgPXoxzCP9dz7bkjnnBU8ffzuLycruPDLrAzcRZv1ablUTo84UiVVYEXFh9QY7KSNUz/R2QdBfIFVc=@vger.kernel.org X-Gm-Message-State: AOJu0Ywgsu9PCLJREhxq562v5FvhD6YWHO4aPS1ZyKYDRAN2uMfq6XbG bArbOMf35g+PkAO2hfv9ngmpiJ7vpvZEytfrPqHRli36XU31WnM23WWwl5M5RC5+/HqXpmsXtho QB4cKx89eCpgn3aOsa4O9j0fgBqVhldlUkPTqthTGtcmsyDVc9zl/6CnOhE6DB9uy1Hg= X-Gm-Gg: Acq92OEXzDgYEtPJXdaBdHKh+1JidTsJ3NQ5UvUUw0ozpmX6dW/spDBcT3hKFuKyie4 T6aoHaSifB90haQrT4Mhy0NECHfX2Uflw2aSSjAL7vYYQM+fYjBkFURdE8tUGWM8DOtc3psFk7b TygoP1iEkw7OzRAdjCa2r0BSYbtnDy+zttbaINcaNzYWnBhoi1uSx9W7J76Gj69yta5rFo3dusU 4hgHOBN4IZUHceoK03L7j0y3oX3gaFIDrlvmay8qQJEBRMEIsjrTA7fuJ0EvDn2jHmZWg5V8GbD RvLgfVqwqhvn7Gw9kbUO38hNJe1gKE4olz7yGj7xqalEP+d0/mNMaI+r0SLnol8gEddlSqZRZ0C GsKfcMwWuARQ4937Q8uObWteclJ9B9waNvsvbcqfThQ6demfKJK4jK6IFkcWiJQRGKz1XEE8jrA u7No9U9kTkr8nwTgC2 X-Received: by 2002:a17:903:3847:b0:2b9:ecb4:a3dd with SMTP id d9443c01a7336-2ba798c2a32mr103025825ad.34.1778222824384; Thu, 07 May 2026 23:47:04 -0700 (PDT) X-Received: by 2002:a17:903:3847:b0:2b9:ecb4:a3dd with SMTP id d9443c01a7336-2ba798c2a32mr103025425ad.34.1778222823674; Thu, 07 May 2026 23:47:03 -0700 (PDT) Received: from [10.133.33.84] (tpe-colo-wan-fw-bordernet.qualcomm.com. [103.229.16.4]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2baf1e374besm10119535ad.47.2026.05.07.23.47.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 May 2026 23:47:03 -0700 (PDT) Message-ID: <80d32bdb-f661-44cb-b529-3d5ce2142af0@oss.qualcomm.com> Date: Fri, 8 May 2026 14:46:58 +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 , "zhenglifeng (A)" Cc: 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> 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-Spam-Details-Enc: AW1haW4tMjYwNTA4MDA2NSBTYWx0ZWRfX3iX8FIW0EayO apvip1tthgRhzYEkqhFiiprkOUwN+7j8oYNrbzWQLD0U8Vz+GXAUYF5BLI685eDpyEq+y7C6uJQ jNeXysc+Y1cTc2DdBPoAwpOht2AgZik/9GtEwgb5MHzszH9fKfdxnBkCqMBJVHXYymMrRc96gXc K44+uE9FOWY/IQ5NrJwng2y+cDrWtUC4kCNELr80xmyLNXcBgg4DhHsrCpKEo5fQHWyc6liLvGk P0o3B9JDfxi85b+Rf4cGZQnGa6GsXy3IQajsKYMHBmwKtTQCuOhNBlmrj82ATMnENFaSzVoKEif 1f1z9a3wr1x9ECbFeJ1o1Wm9wUpbT/it9vi4UD/q98xVESiT0AafhTtjatshS3GdrvJXQM5UJH4 0QlrAtRmBp6h8EuLJhJgjn09JLpUBnslCBeYbRl4g/yM+xaVWjdw029efUYGBdsgZwaDBLof9ho ScsebhkLaK/E93vta1A== X-Proofpoint-GUID: VuX2nE2L9xKekGborxOPN6BvpGB7gTK8 X-Proofpoint-ORIG-GUID: VuX2nE2L9xKekGborxOPN6BvpGB7gTK8 X-Authority-Analysis: v=2.4 cv=NKblPU6g c=1 sm=1 tr=0 ts=69fd86e9 cx=c_pps a=cmESyDAEBpBGqyK7t0alAg==:117 a=nuhDOHQX5FNHPW3J6Bj6AA==:17 a=IkcTkHD0fZMA:10 a=NGcC8JguVDcA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=eoimf2acIAo5FJnRuUoq:22 a=VwQbUJbxAAAA:8 a=ujytlxt2ZZPjNJFSC5gA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=1OuFwYUASf3TG4hYMiVC: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-07_02,2026-05-06_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 impostorscore=0 spamscore=0 clxscore=1015 malwarescore=0 lowpriorityscore=0 phishscore=0 priorityscore=1501 suspectscore=0 adultscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2604200000 definitions=main-2605080065 On 5/7/2026 5:33 PM, Viresh Kumar wrote: > On 23-04-26, 15:12, zhenglifeng (A) wrote: >> Yes, I think you are right. The behaviors are not the same. I modified this >> just in order to keep it consistent with the case exceeding down_threshold. >> I'm not sure if this change of behavior is reasonable. Perhaps Rafael or >> Viresh could give us some advice. > >>>> diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufreq_conservative.c >>>> @@ -104,7 +104,7 @@ static unsigned int cs_dbs_update(struct cpufreq_policy *policy) >>>>           dbs_info->down_skip = 0; >>>>             /* if we are already at full speed then break out early */ >>>> -        if (requested_freq == policy->max) >>>> +        if (dbs_info->requested_freq == policy->max) >>>>               goto out; > >>>> -        if (requested_freq == policy->min) >>>> +        if (dbs_info->requested_freq == policy->min) > > What about dropping these `if` blocks completely ? i.e. always call > __cpufreq_driver_target(). > > __cpufreq_driver_target() already have similar checks in place to optimize > unnecessary freq changes. We don't really need callers to do the same. > Thanks Viresh a lot, 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. -- Thx and BRs, Zhongqiu Han