[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[PATCH v4 10/15] xen/cpufreq: only set gov NULL when cpufreq_driver.setpolicy is NULL
- To: <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: Penny Zheng <Penny.Zheng@xxxxxxx>
- Date: Mon, 14 Apr 2025 15:40:51 +0800
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=OYKj+c3hCaRMUyQyZHcVEmjkaY1O+Uy8Y1vxZ7yGoGc=; b=u8B8aY1FzgDL+Vi2ZfmXx/p/codOUEwnu4MXO2hxDRBqYJ8bbtMZ6pYLNYjED1hzX8Pbfe1bV595Ml27/12RZl35UWDG0w7GeURSC5W/Y1V1mo1CGazZGqdhN9blNlx+XFJz4dHUPdzriBsH2/BQ94ZyeQWmlnT89CyU/VGm+x0EDfRfFtk8i9ybJd24rxgN085OryXpTj5Fnsr8vHSDFw8y2m4cthszs/iqzzmizgUdF7Eb8GOim8iwK2V5LT/ZT52DVqnDumd0TOB/jEl4NtqzuFIkqeKXlKwfRBf8KV3Y7tzPxaTh9y0XDP1wImuqmcWiTLrl7K2NaXTnK6HF5w==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=W/t1RcNKfOlQuF2W8Tdsq6UDXxUGpxJBJDhC55ZMlpvpjk2/msHLHmXnAROWZ6yfzB+92zIxooEGTbKhmpB6yoe5lt/0ZQhDRJsXbzuc/PCUEXdsBctVC45LFDMZnC4QmkSOUap9aF42QQTg5qVBx1bKVPVF+hwGJizL8OwczJ6L2lgrC0EwluFr9wL6rCL3iKEyuuABKvYb4I7B8RXHbznzqZ6EdEgB5uoRdbDU82LK/eNbUKtxBz2e6xQ52l6TqVNHGLiH1mnXo0AN1LtgpJYyV8NaW2Syx+2Cq+CzmrR0yGMukr27So7RjycpRQhap4axI/zckl3yXeE+yb+OqQ==
- Cc: <ray.huang@xxxxxxx>, Penny Zheng <Penny.Zheng@xxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>
- Delivery-date: Mon, 14 Apr 2025 07:41:49 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
amd-cppc on active mode bypasses the scaling governor layer, and
provides its own P-state selection algorithms in hardware. Consequently,
when it is used, the driver's -> setpolicy() callback is invoked
to register per-CPU utilization update callbacks, not the ->target()
callback.
So, only when cpufreq_driver.setpolicy is NULL, we need to deliberately
set old gov as NULL to trigger the according gov starting.
Signed-off-by: Penny Zheng <Penny.Zheng@xxxxxxx>
Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
---
v3 -> v4:
- fix indentation and this commit is independent of all earlier patches
---
xen/drivers/cpufreq/cpufreq.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
index 818668c99c..2e392110d8 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -396,7 +396,13 @@ int cpufreq_add_cpu(unsigned int cpu)
domain_info.num_processors) )
{
memcpy(&new_policy, policy, sizeof(struct cpufreq_policy));
- policy->governor = NULL;
+
+ /*
+ * Only when cpufreq_driver.setpolicy == NULL, we need to deliberately
+ * set old gov as NULL to trigger the according gov starting.
+ */
+ if ( cpufreq_driver.setpolicy == NULL )
+ policy->governor = NULL;
cpufreq_cmdline_common_para(&new_policy);
--
2.34.1
|