cpufreq: intel_pstate: Fix CPU lowest Frequency bug when offline/online for passive
Message ID | 20231107025838.2806500-1-ruanjinjie@huawei.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:8f47:0:b0:403:3b70:6f57 with SMTP id j7csp3064905vqu; Mon, 6 Nov 2023 18:59:52 -0800 (PST) X-Google-Smtp-Source: AGHT+IFpjjCFbTDo4IzVDrfsAm693AJhmMLbJQbXn1H/cMGYQ83+i/gDOCeyaB8N8s19Kg7mUBz/ X-Received: by 2002:a67:b802:0:b0:45d:a78f:c5f9 with SMTP id i2-20020a67b802000000b0045da78fc5f9mr8343661vsf.24.1699325992076; Mon, 06 Nov 2023 18:59:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1699325992; cv=none; d=google.com; s=arc-20160816; b=GelCJ07ucstHUhMFcVe7ALUFGWiYmyKEOYDeumDuja2GQd84MBm+eCPGgG+V+eL2KQ /EUzmiFeh3WHchb+7BT+C9EJCl8VxcdN1FXP6Wrh+i0bvxmjHQYvFEOsZ7RcGEePYpfE b3dfLo1v+EHnP69DgNP0HrtnFQzCpdOvUdaIlDVP/avOTJc3hfUJjQEUcI5d7g7vcu8H 9aPZa6ClT9pOCQ/gpRkj69e4wUQ+vBE/1JvDdnIy/SzWHpi1ZOggwbhnPgOpMbrQcmsx shbdtKtQx5oLffAWoXc9/bx6WBWk3x3poPR215ZIxbmTGbA5coB98l6XR3E36/B+YV2E dseQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=W5U+uKg/fGrQmIIu8dfkcD8ChkIa9bZqNReYabNxE28=; fh=P+D61ld8D5wv3DaJt2LblO52fpgfAd6hrmSXwMUXrfc=; b=gtMWxi7vxGEEhSTCB6PNhNCHl09ZDv3mLfdAEHXeaOmh+tEhW/YfPYkeyqL+OXrkaA jrxOAhFia9/dQkMND55AaumoKDmmTbl3JdN4CcezEHgo7hQJZ2gRzoTSlqFeCUqHgdm+ dUzpgzsnKkerkjVgnNl59TqqhbnVVr0/7j0Pt+SjKng+q06CcqFpsLf6b0m8n/KnDh7L oDGjfhGw7aZ5c2DZ1N8ZnuoF3QV3MNz9GLzrCNnEUW5cprrL/RkeLYU1r4nBesn/ml3g HXUouPbUrwqPUW9nfW+uM4du13bOTanUwZ+vbBo/L6leAf4KyIUxNA4r0DznEsqIVJ+y /Z7g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from fry.vger.email (fry.vger.email. [23.128.96.38]) by mx.google.com with ESMTPS id y187-20020a6364c4000000b005b99ea783aasi1115925pgb.755.2023.11.06.18.59.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Nov 2023 18:59:52 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id CC4238027484; Mon, 6 Nov 2023 18:59:49 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233330AbjKGC7O (ORCPT <rfc822;heyuhang3455@gmail.com> + 33 others); Mon, 6 Nov 2023 21:59:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57084 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229646AbjKGC7N (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 6 Nov 2023 21:59:13 -0500 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DBAF811C; Mon, 6 Nov 2023 18:59:08 -0800 (PST) Received: from kwepemi500008.china.huawei.com (unknown [172.30.72.53]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4SPXwy5byKzvQPx; Tue, 7 Nov 2023 10:58:58 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemi500008.china.huawei.com (7.221.188.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Tue, 7 Nov 2023 10:59:05 +0800 From: Jinjie Ruan <ruanjinjie@huawei.com> To: <linux-pm@vger.kernel.org>, <linux-kernel@vger.kernel.org>, Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>, Len Brown <lenb@kernel.org>, "Rafael J. Wysocki" <rafael@kernel.org>, Viresh Kumar <viresh.kumar@linaro.org> CC: <ruanjinjie@huawei.com>, <zhaowenhui8@huawei.com> Subject: [PATCH] cpufreq: intel_pstate: Fix CPU lowest Frequency bug when offline/online for passive Date: Tue, 7 Nov 2023 10:58:38 +0800 Message-ID: <20231107025838.2806500-1-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.90.53.73] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To kwepemi500008.china.huawei.com (7.221.188.139) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Mon, 06 Nov 2023 18:59:49 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1781872451760450064 X-GMAIL-MSGID: 1781872451760450064 |
Series |
cpufreq: intel_pstate: Fix CPU lowest Frequency bug when offline/online for passive
|
|
Commit Message
Jinjie Ruan
Nov. 7, 2023, 2:58 a.m. UTC
There is a bug in passive mode for intel pstate when
CONFIG_X86_INTEL_PSTATE = y and configure intel_pstate = passive in command
line. On Ice Lake server, although the performance tuner is used, the CPU
have the lowest frequency in scaling_cur_freq after the CPU goes offline and
then goes online, running the same infinite loop load.
How to reproduce:
cat while_true.c
#include <stdio.h>
void main(void)
{
while(1);
}
[root@localhost freq_test]# cat test.sh
#!/bin/bash
cat /sys/devices/system/cpu/cpu${1}/cpufreq/scaling_cur_freq
cat /sys/devices/system/cpu/cpu${1}/cpufreq/scaling_governor
taskset -c ${1} ./while_true &
sleep 1s
cat /sys/devices/system/cpu/cpu${1}/cpufreq/scaling_cur_freq
echo 0 > /sys/devices/system/cpu/cpu${1}/online
sleep 1s
cat /sys/devices/system/cpu/cpu${1}/cpufreq/scaling_cur_freq
sleep 1s
echo 1 > /sys/devices/system/cpu/cpu${1}/online
cat /sys/devices/system/cpu/cpu${1}/cpufreq/scaling_cur_freq
taskset -c ${1} ./while_true &
sleep 1s
cat /sys/devices/system/cpu/cpu${1}/cpufreq/scaling_cur_freq
sleep 1s
cat /sys/devices/system/cpu/cpu${1}/cpufreq/scaling_cur_freq
sleep 1s
cat /sys/devices/system/cpu/cpu${1}/cpufreq/scaling_cur_freq
The CPU frequency is adjusted to the minimum after offline and online:
[root@localhost freq_test]# sh test.sh 20
2300000
performance
2299977
cat: /sys/devices/system/cpu/cpu20/cpufreq/scaling_cur_freq: Device or
resource busy
800000
800000
800000
799992
[root@localhost freq_test]# sh test.sh 21
2300000
performance
2300000
cat: /sys/devices/system/cpu/cpu21/cpufreq/scaling_cur_freq: Device or
resource busy
800000
800000
800000
800000
As in __cpufreq_driver_target(), the cpufreq core will not call intel
cpufreq's target() callback if the target freq is equal with policy->cur
and do not set CPUFREQ_NEED_UPDATE_LIMITS flag, but the hardware also not
proactively keep CPU with the policy->cur frequency. So also set
CPUFREQ_NEED_UPDATE_LIMITS for passive mode. After applying this patch,
the CPU frequency is consistent as what performance tuner expected after
CPU offline and online as below:
[root@localhost freq_test]# sh test.sh 20
2300000
performance
2300000
cat: /sys/devices/system/cpu/cpu20/cpufreq/scaling_cur_freq: Device or resource busy
2300000
2300000
2299977
2299977
[root@localhost freq_test]# sh test.sh 21
2300000
performance
2300000
cat: /sys/devices/system/cpu/cpu21/cpufreq/scaling_cur_freq: Device or resource busy
2300000
2300000
2300000
2300000
[root@localhost freq_test]# cat /sys/devices/system/cpu/intel_pstate/status
passive
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
drivers/cpufreq/intel_pstate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
Ping. On 2023/11/7 10:58, Jinjie Ruan wrote: > There is a bug in passive mode for intel pstate when > CONFIG_X86_INTEL_PSTATE = y and configure intel_pstate = passive in command > line. On Ice Lake server, although the performance tuner is used, the CPU > have the lowest frequency in scaling_cur_freq after the CPU goes offline and > then goes online, running the same infinite loop load. > > How to reproduce: > > cat while_true.c > #include <stdio.h> > void main(void) > { > while(1); > } > > [root@localhost freq_test]# cat test.sh > #!/bin/bash > > cat /sys/devices/system/cpu/cpu${1}/cpufreq/scaling_cur_freq > cat /sys/devices/system/cpu/cpu${1}/cpufreq/scaling_governor > taskset -c ${1} ./while_true & > sleep 1s > > cat /sys/devices/system/cpu/cpu${1}/cpufreq/scaling_cur_freq > > echo 0 > /sys/devices/system/cpu/cpu${1}/online > > sleep 1s > cat /sys/devices/system/cpu/cpu${1}/cpufreq/scaling_cur_freq > > sleep 1s > > echo 1 > /sys/devices/system/cpu/cpu${1}/online > cat /sys/devices/system/cpu/cpu${1}/cpufreq/scaling_cur_freq > > taskset -c ${1} ./while_true & > > sleep 1s > cat /sys/devices/system/cpu/cpu${1}/cpufreq/scaling_cur_freq > > sleep 1s > cat /sys/devices/system/cpu/cpu${1}/cpufreq/scaling_cur_freq > > sleep 1s > cat /sys/devices/system/cpu/cpu${1}/cpufreq/scaling_cur_freq > > The CPU frequency is adjusted to the minimum after offline and online: > > [root@localhost freq_test]# sh test.sh 20 > 2300000 > performance > 2299977 > cat: /sys/devices/system/cpu/cpu20/cpufreq/scaling_cur_freq: Device or > resource busy > 800000 > 800000 > 800000 > 799992 > [root@localhost freq_test]# sh test.sh 21 > 2300000 > performance > 2300000 > cat: /sys/devices/system/cpu/cpu21/cpufreq/scaling_cur_freq: Device or > resource busy > 800000 > 800000 > 800000 > 800000 > > As in __cpufreq_driver_target(), the cpufreq core will not call intel > cpufreq's target() callback if the target freq is equal with policy->cur > and do not set CPUFREQ_NEED_UPDATE_LIMITS flag, but the hardware also not > proactively keep CPU with the policy->cur frequency. So also set > CPUFREQ_NEED_UPDATE_LIMITS for passive mode. After applying this patch, > the CPU frequency is consistent as what performance tuner expected after > CPU offline and online as below: > > [root@localhost freq_test]# sh test.sh 20 > 2300000 > performance > 2300000 > cat: /sys/devices/system/cpu/cpu20/cpufreq/scaling_cur_freq: Device or resource busy > 2300000 > 2300000 > 2299977 > 2299977 > [root@localhost freq_test]# sh test.sh 21 > 2300000 > performance > 2300000 > cat: /sys/devices/system/cpu/cpu21/cpufreq/scaling_cur_freq: Device or resource busy > 2300000 > 2300000 > 2300000 > 2300000 > [root@localhost freq_test]# cat /sys/devices/system/cpu/intel_pstate/status > passive > > Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> > --- > drivers/cpufreq/intel_pstate.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c > index a534a1f7f1ee..73403f1292b0 100644 > --- a/drivers/cpufreq/intel_pstate.c > +++ b/drivers/cpufreq/intel_pstate.c > @@ -3091,7 +3091,7 @@ static int intel_cpufreq_suspend(struct cpufreq_policy *policy) > } > > static struct cpufreq_driver intel_cpufreq = { > - .flags = CPUFREQ_CONST_LOOPS, > + .flags = CPUFREQ_CONST_LOOPS | CPUFREQ_NEED_UPDATE_LIMITS, > .verify = intel_cpufreq_verify_policy, > .target = intel_cpufreq_target, > .fast_switch = intel_cpufreq_fast_switch,
On Mon, Nov 13, 2023 at 7:18 AM Jinjie Ruan <ruanjinjie@huawei.com> wrote: > > Ping. I see the problem, but I'm not sure if the approach taken in the patch is the best one, as it has side effects. > On 2023/11/7 10:58, Jinjie Ruan wrote: > > There is a bug in passive mode for intel pstate when > > CONFIG_X86_INTEL_PSTATE = y and configure intel_pstate = passive in command > > line. On Ice Lake server, although the performance tuner is used, the CPU > > have the lowest frequency in scaling_cur_freq after the CPU goes offline and > > then goes online, running the same infinite loop load. > > > > How to reproduce: > > > > cat while_true.c > > #include <stdio.h> > > void main(void) > > { > > while(1); > > } > > > > [root@localhost freq_test]# cat test.sh > > #!/bin/bash > > > > cat /sys/devices/system/cpu/cpu${1}/cpufreq/scaling_cur_freq > > cat /sys/devices/system/cpu/cpu${1}/cpufreq/scaling_governor > > taskset -c ${1} ./while_true & > > sleep 1s > > > > cat /sys/devices/system/cpu/cpu${1}/cpufreq/scaling_cur_freq > > > > echo 0 > /sys/devices/system/cpu/cpu${1}/online > > > > sleep 1s > > cat /sys/devices/system/cpu/cpu${1}/cpufreq/scaling_cur_freq > > > > sleep 1s > > > > echo 1 > /sys/devices/system/cpu/cpu${1}/online > > cat /sys/devices/system/cpu/cpu${1}/cpufreq/scaling_cur_freq > > > > taskset -c ${1} ./while_true & > > > > sleep 1s > > cat /sys/devices/system/cpu/cpu${1}/cpufreq/scaling_cur_freq > > > > sleep 1s > > cat /sys/devices/system/cpu/cpu${1}/cpufreq/scaling_cur_freq > > > > sleep 1s > > cat /sys/devices/system/cpu/cpu${1}/cpufreq/scaling_cur_freq > > > > The CPU frequency is adjusted to the minimum after offline and online: > > > > [root@localhost freq_test]# sh test.sh 20 > > 2300000 > > performance > > 2299977 > > cat: /sys/devices/system/cpu/cpu20/cpufreq/scaling_cur_freq: Device or > > resource busy > > 800000 > > 800000 > > 800000 > > 799992 > > [root@localhost freq_test]# sh test.sh 21 > > 2300000 > > performance > > 2300000 > > cat: /sys/devices/system/cpu/cpu21/cpufreq/scaling_cur_freq: Device or > > resource busy > > 800000 > > 800000 > > 800000 > > 800000 > > > > As in __cpufreq_driver_target(), the cpufreq core will not call intel > > cpufreq's target() callback if the target freq is equal with policy->cur > > and do not set CPUFREQ_NEED_UPDATE_LIMITS flag, but the hardware also not > > proactively keep CPU with the policy->cur frequency. So also set > > CPUFREQ_NEED_UPDATE_LIMITS for passive mode. After applying this patch, > > the CPU frequency is consistent as what performance tuner expected after > > CPU offline and online as below: > > > > [root@localhost freq_test]# sh test.sh 20 > > 2300000 > > performance > > 2300000 > > cat: /sys/devices/system/cpu/cpu20/cpufreq/scaling_cur_freq: Device or resource busy > > 2300000 > > 2300000 > > 2299977 > > 2299977 > > [root@localhost freq_test]# sh test.sh 21 > > 2300000 > > performance > > 2300000 > > cat: /sys/devices/system/cpu/cpu21/cpufreq/scaling_cur_freq: Device or resource busy > > 2300000 > > 2300000 > > 2300000 > > 2300000 > > [root@localhost freq_test]# cat /sys/devices/system/cpu/intel_pstate/status > > passive > > > > Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> > > --- > > drivers/cpufreq/intel_pstate.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c > > index a534a1f7f1ee..73403f1292b0 100644 > > --- a/drivers/cpufreq/intel_pstate.c > > +++ b/drivers/cpufreq/intel_pstate.c > > @@ -3091,7 +3091,7 @@ static int intel_cpufreq_suspend(struct cpufreq_policy *policy) > > } > > > > static struct cpufreq_driver intel_cpufreq = { > > - .flags = CPUFREQ_CONST_LOOPS, > > + .flags = CPUFREQ_CONST_LOOPS | CPUFREQ_NEED_UPDATE_LIMITS, > > .verify = intel_cpufreq_verify_policy, > > .target = intel_cpufreq_target, > > .fast_switch = intel_cpufreq_fast_switch,
On 2023/11/21 1:16, Rafael J. Wysocki wrote: > On Mon, Nov 13, 2023 at 7:18 AM Jinjie Ruan <ruanjinjie@huawei.com> wrote: >> >> Ping. > > I see the problem, but I'm not sure if the approach taken in the patch > is the best one, as it has side effects. Could you please make it more clear, what are the side effects? I'm not sure about the possible negative effects of the patch. > >> On 2023/11/7 10:58, Jinjie Ruan wrote: >>> There is a bug in passive mode for intel pstate when >>> CONFIG_X86_INTEL_PSTATE = y and configure intel_pstate = passive in command >>> line. On Ice Lake server, although the performance tuner is used, the CPU >>> have the lowest frequency in scaling_cur_freq after the CPU goes offline and >>> then goes online, running the same infinite loop load. >>> >>> How to reproduce: >>> >>> cat while_true.c >>> #include <stdio.h> >>> void main(void) >>> { >>> while(1); >>> } >>> >>> [root@localhost freq_test]# cat test.sh >>> #!/bin/bash >>> >>> cat /sys/devices/system/cpu/cpu${1}/cpufreq/scaling_cur_freq >>> cat /sys/devices/system/cpu/cpu${1}/cpufreq/scaling_governor >>> taskset -c ${1} ./while_true & >>> sleep 1s >>> >>> cat /sys/devices/system/cpu/cpu${1}/cpufreq/scaling_cur_freq >>> >>> echo 0 > /sys/devices/system/cpu/cpu${1}/online >>> >>> sleep 1s >>> cat /sys/devices/system/cpu/cpu${1}/cpufreq/scaling_cur_freq >>> >>> sleep 1s >>> >>> echo 1 > /sys/devices/system/cpu/cpu${1}/online >>> cat /sys/devices/system/cpu/cpu${1}/cpufreq/scaling_cur_freq >>> >>> taskset -c ${1} ./while_true & >>> >>> sleep 1s >>> cat /sys/devices/system/cpu/cpu${1}/cpufreq/scaling_cur_freq >>> >>> sleep 1s >>> cat /sys/devices/system/cpu/cpu${1}/cpufreq/scaling_cur_freq >>> >>> sleep 1s >>> cat /sys/devices/system/cpu/cpu${1}/cpufreq/scaling_cur_freq >>> >>> The CPU frequency is adjusted to the minimum after offline and online: >>> >>> [root@localhost freq_test]# sh test.sh 20 >>> 2300000 >>> performance >>> 2299977 >>> cat: /sys/devices/system/cpu/cpu20/cpufreq/scaling_cur_freq: Device or >>> resource busy >>> 800000 >>> 800000 >>> 800000 >>> 799992 >>> [root@localhost freq_test]# sh test.sh 21 >>> 2300000 >>> performance >>> 2300000 >>> cat: /sys/devices/system/cpu/cpu21/cpufreq/scaling_cur_freq: Device or >>> resource busy >>> 800000 >>> 800000 >>> 800000 >>> 800000 >>> >>> As in __cpufreq_driver_target(), the cpufreq core will not call intel >>> cpufreq's target() callback if the target freq is equal with policy->cur >>> and do not set CPUFREQ_NEED_UPDATE_LIMITS flag, but the hardware also not >>> proactively keep CPU with the policy->cur frequency. So also set >>> CPUFREQ_NEED_UPDATE_LIMITS for passive mode. After applying this patch, >>> the CPU frequency is consistent as what performance tuner expected after >>> CPU offline and online as below: >>> >>> [root@localhost freq_test]# sh test.sh 20 >>> 2300000 >>> performance >>> 2300000 >>> cat: /sys/devices/system/cpu/cpu20/cpufreq/scaling_cur_freq: Device or resource busy >>> 2300000 >>> 2300000 >>> 2299977 >>> 2299977 >>> [root@localhost freq_test]# sh test.sh 21 >>> 2300000 >>> performance >>> 2300000 >>> cat: /sys/devices/system/cpu/cpu21/cpufreq/scaling_cur_freq: Device or resource busy >>> 2300000 >>> 2300000 >>> 2300000 >>> 2300000 >>> [root@localhost freq_test]# cat /sys/devices/system/cpu/intel_pstate/status >>> passive >>> >>> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> >>> --- >>> drivers/cpufreq/intel_pstate.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c >>> index a534a1f7f1ee..73403f1292b0 100644 >>> --- a/drivers/cpufreq/intel_pstate.c >>> +++ b/drivers/cpufreq/intel_pstate.c >>> @@ -3091,7 +3091,7 @@ static int intel_cpufreq_suspend(struct cpufreq_policy *policy) >>> } >>> >>> static struct cpufreq_driver intel_cpufreq = { >>> - .flags = CPUFREQ_CONST_LOOPS, >>> + .flags = CPUFREQ_CONST_LOOPS | CPUFREQ_NEED_UPDATE_LIMITS, >>> .verify = intel_cpufreq_verify_policy, >>> .target = intel_cpufreq_target, >>> .fast_switch = intel_cpufreq_fast_switch, >
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index a534a1f7f1ee..73403f1292b0 100644 --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -3091,7 +3091,7 @@ static int intel_cpufreq_suspend(struct cpufreq_policy *policy) } static struct cpufreq_driver intel_cpufreq = { - .flags = CPUFREQ_CONST_LOOPS, + .flags = CPUFREQ_CONST_LOOPS | CPUFREQ_NEED_UPDATE_LIMITS, .verify = intel_cpufreq_verify_policy, .target = intel_cpufreq_target, .fast_switch = intel_cpufreq_fast_switch,