Received: by 2002:a05:7412:8521:b0:e2:908c:2ebd with SMTP id t33csp2544089rdf; Mon, 6 Nov 2023 18:59:34 -0800 (PST) X-Google-Smtp-Source: AGHT+IHGc5M02Hs6/vqedUfpXngSeJpXeEIqnxyBNVRdHjR1PtAQrv2klOoU/fBas1L8pY8R782T X-Received: by 2002:a1f:9c11:0:b0:49a:b6c7:ddfc with SMTP id f17-20020a1f9c11000000b0049ab6c7ddfcmr27173493vke.1.1699325973857; Mon, 06 Nov 2023 18:59:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1699325973; cv=none; d=google.com; s=arc-20160816; b=DpICNmbvP1rUeK7ISmKWDJlDWquiX/IyX338ZIeKNt7ovO2BY5dsKhNxsl3pMbIlPO HWa8/O68eydhqyAheXC7El7yxAjvTE/v4EB7GoPU3eFGI2g0iGUQhx2HTowcAE5dVXlT K6rR3iHE3ZjMlMTYEtrrWA/JVbBn0658YeORpL8/nfFUo2YfkevA2bqN1X480ZNzxwVe Viaq9Xt1fy1xya6H26tLVMuYK9zuHYhR688odwR/gir94bJq2YQ46fo17s9BktlrelIc oxcnsMNDXqEY5tUq0aj6Jgx4Q8b0VE3kEtpqwHqsDLz8Mxtq8t5W603ZYMHaPmR9b5Zo cisw== 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 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id q7-20020a632a07000000b005b93bfe91f3si1028874pgq.577.2023.11.06.18.59.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Nov 2023 18:59:33 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 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 50B9E802B540; Mon, 6 Nov 2023 18:59:31 -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 S232539AbjKGC7O (ORCPT + 99 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 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: 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:31 -0800 (PST) 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, -- 2.34.1