From patchwork Tue Nov 7 02:58:38 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jinjie Ruan X-Patchwork-Id: 162250 Return-Path: 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 + 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 ); 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 To: , , Srinivas Pandruvada , Len Brown , "Rafael J. Wysocki" , Viresh Kumar CC: , 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 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: 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 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 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 --- 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,