From patchwork Fri Nov 29 15:56:15 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Rafael J. Wysocki" X-Patchwork-Id: 846234 Received: from cloudserver094114.home.pl (cloudserver094114.home.pl [79.96.170.134]) (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 3B28A14E2E6; Fri, 29 Nov 2024 16:28:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=79.96.170.134 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732897711; cv=none; b=hIrXiMEZKhrxgtu4V2jgIHl0IDhjQold0LxVx1IpMRBxx6fuqantVkq/6RC1Nyj3rFy244H9Ku+LeKb2vA7GFELfhVNCg1tcOVkwFojbdjwXUZL0DZZwzubbfAo3BMe5NPO7Welqvd586fwZ+HVzmk60b4a8xevwAsTVcoz+70o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732897711; c=relaxed/simple; bh=HMGBZOXSMMvv1IfoZw8Sx2HA/3BEClrax5ORvrtMt1c=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=uAm3EcpV4PPDpcHCkl/x8ucOHVpkE3RF9Ltn+lGa0XSdgQNke91A14g2aq0qVmhdVA5IRNqGJYb76yetJmKe9AYc/g3qPK2MOv8RjdDuIKxCizJ+lj7iG+V1sHE6bgTtHhigAOD26UQrs+ashtmR+t1DvLEcw8iB18wQve/0u8g= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rjwysocki.net; spf=pass smtp.mailfrom=rjwysocki.net; dkim=pass (2048-bit key) header.d=rjwysocki.net header.i=@rjwysocki.net header.b=WayB0odm; arc=none smtp.client-ip=79.96.170.134 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rjwysocki.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rjwysocki.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rjwysocki.net header.i=@rjwysocki.net header.b="WayB0odm" Received: from localhost (127.0.0.1) (HELO v370.home.net.pl) by /usr/run/smtp (/usr/run/postfix/private/idea_relay_lmtp) via UNIX with SMTP (IdeaSmtpServer 6.2.1) id 62129d98bd018b2f; Fri, 29 Nov 2024 17:28:27 +0100 Received: from kreacher.localnet (unknown [195.136.19.94]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by cloudserver094114.home.pl (Postfix) with ESMTPSA id 9874DA47B8B; Fri, 29 Nov 2024 17:28:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rjwysocki.net; s=dkim; t=1732897707; bh=HMGBZOXSMMvv1IfoZw8Sx2HA/3BEClrax5ORvrtMt1c=; h=From:Subject:Date; b=WayB0odmVKpfkTFhPGYu6Q3Jf/EApccNMChSPAFk/PcN4BVo+3wCyYfkE90EXoYkV a6wOAcs/KNaHSdajOFqvqLMdkdWZMGvCnz9AIJUB20Ccgmen/8UZIx08EcbeOefExH RLNMhXucYzeM/wOWUrhPwdx8hsohYkgraR2ltNI943v0/opq/ShyAxrmnHwroJ3mMI LoIPaZGZ9j3qKnS/8c9oQQsnrrySgd3isxqD40rYgBZNIzQGaYXU1UPj8GuPF6tJKG SgjSFs0ntyi2HJ3zp6MlGKW96HPpOHXhhljRzsi4+Rq7a8NOGye0EQvEU8mir7vnET 9uWwRKPJfDyCw== From: "Rafael J. Wysocki" To: Linux PM Cc: LKML , Lukasz Luba , Peter Zijlstra , Srinivas Pandruvada , Dietmar Eggemann , Morten Rasmussen , Vincent Guittot , Ricardo Neri , Pierre Gondois Subject: [RFC][PATCH v021 1/9] cpufreq: intel_pstate: Use CPPC to get scaling factors Date: Fri, 29 Nov 2024 16:56:15 +0100 Message-ID: <4992622.31r3eYUQgx@rjwysocki.net> In-Reply-To: <5861970.DvuYhMxLoT@rjwysocki.net> References: <5861970.DvuYhMxLoT@rjwysocki.net> Precedence: bulk X-Mailing-List: linux-pm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-CLIENT-IP: 195.136.19.94 X-CLIENT-HOSTNAME: 195.136.19.94 X-VADE-SPAMSTATE: clean X-VADE-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefuddrheefgdekjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfjqffogffrnfdpggftiffpkfenuceurghilhhouhhtmecuudehtdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkjghfggfgtgesthfuredttddtjeenucfhrhhomhepfdftrghfrggvlhculfdrucghhihsohgtkhhifdcuoehrjhifsehrjhifhihsohgtkhhirdhnvghtqeenucggtffrrghtthgvrhhnpedvffeuiedtgfdvtddugeeujedtffetteegfeekffdvfedttddtuefhgeefvdejhfenucfkphepudelhedrudefiedrudelrdelgeenucevlhhushhtvghrufhiiigvpedunecurfgrrhgrmhepihhnvghtpeduleehrddufeeirdduledrleegpdhhvghlohepkhhrvggrtghhvghrrdhlohgtrghlnhgvthdpmhgrihhlfhhrohhmpehrjhifsehrjhifhihsohgtkhhirdhnvghtpdhnsggprhgtphhtthhopedutddprhgtphhtthhopehlihhnuhigqdhpmhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehluhhkrghsiidrlhhusggrsegrrhhmrdgtohhmpdhrtghpthhtohepphgvthgvrhiisehinhhfrhgruggvrggurdhorhhgpdhrtghpthhtohepshhrihhnihhvrghsrdhprghnughruhhvrggurgeslhhinhhugidrihhnthg X-DCC--Metrics: v370.home.net.pl 1024; Body=10 Fuz1=10 Fuz2=10 From: Rafael J. Wysocki If the P-core hybrid scaling factor for the given processor model is not known, use CPPC to compute hybrid scaling factors for all CPUs. Since the current default hybrid scaling factor is only suitable for a few early hybrid platforms, add intel_hybrid_scaling_factor[] entries for them and initialize the scaling factor to zero ("unknown") by default. Signed-off-by: Rafael J. Wysocki --- drivers/cpufreq/intel_pstate.c | 59 +++++++++++++++++++++++------------------ 1 file changed, 34 insertions(+), 25 deletions(-) Index: linux-pm/drivers/cpufreq/intel_pstate.c =================================================================== --- linux-pm.orig/drivers/cpufreq/intel_pstate.c +++ linux-pm/drivers/cpufreq/intel_pstate.c @@ -28,6 +28,7 @@ #include #include #include +#include #include #include @@ -302,11 +303,11 @@ static bool hwp_is_hybrid; static struct cpufreq_driver *intel_pstate_driver __read_mostly; -#define HYBRID_SCALING_FACTOR 78741 +#define HYBRID_SCALING_FACTOR_ADL 78741 #define HYBRID_SCALING_FACTOR_MTL 80000 #define HYBRID_SCALING_FACTOR_LNL 86957 -static int hybrid_scaling_factor = HYBRID_SCALING_FACTOR; +static int hybrid_scaling_factor; static inline int core_get_scaling(void) { @@ -414,18 +415,15 @@ static int intel_pstate_get_cppc_guarant static int intel_pstate_cppc_get_scaling(int cpu) { struct cppc_perf_caps cppc_perf; - int ret; - - ret = cppc_get_perf_caps(cpu, &cppc_perf); /* - * If the nominal frequency and the nominal performance are not - * zero and the ratio between them is not 100, return the hybrid - * scaling factor. - */ - if (!ret && cppc_perf.nominal_perf && cppc_perf.nominal_freq && - cppc_perf.nominal_perf * 100 != cppc_perf.nominal_freq) - return hybrid_scaling_factor; + * Compute the perf-to-frequency scaling factor for the given CPU if + * possible, unless it would be 0. + */ + if (!cppc_get_perf_caps(cpu, &cppc_perf) && + cppc_perf.nominal_perf && cppc_perf.nominal_freq) + return div_u64(cppc_perf.nominal_freq * KHZ_PER_MHZ, + cppc_perf.nominal_perf); return core_get_scaling(); } @@ -2211,24 +2209,30 @@ static void hybrid_get_type(void *data) static int hwp_get_cpu_scaling(int cpu) { - u8 cpu_type = 0; + if (hybrid_scaling_factor) { + u8 cpu_type = 0; + + smp_call_function_single(cpu, hybrid_get_type, &cpu_type, 1); - smp_call_function_single(cpu, hybrid_get_type, &cpu_type, 1); - /* P-cores have a smaller perf level-to-freqency scaling factor. */ - if (cpu_type == 0x40) - return hybrid_scaling_factor; + /* + * Return the hybrid scaling factor for P-cores and use the + * default core scaling for E-cores. + */ + if (cpu_type == 0x40) + return hybrid_scaling_factor; - /* Use default core scaling for E-cores */ - if (cpu_type == 0x20) + if (cpu_type == 0x20) + return core_get_scaling(); + } + + /* Use core scaling on non-hybrid systems. */ + if (!cpu_feature_enabled(X86_FEATURE_HYBRID_CPU)) return core_get_scaling(); /* - * If reached here, this system is either non-hybrid (like Tiger - * Lake) or hybrid-capable (like Alder Lake or Raptor Lake) with - * no E cores (in which case CPUID for hybrid support is 0). - * - * The CPPC nominal_frequency field is 0 for non-hybrid systems, - * so the default core scaling will be used for them. + * The system is hybrid, but the hybrid scaling factor is not known or + * the CPU type is not one of the above, so use CPPC to compute the + * scaling factor for this CPU. */ return intel_pstate_cppc_get_scaling(cpu); } @@ -3665,6 +3669,11 @@ static const struct x86_cpu_id intel_epp }; static const struct x86_cpu_id intel_hybrid_scaling_factor[] = { + X86_MATCH_VFM(INTEL_ALDERLAKE, HYBRID_SCALING_FACTOR_ADL), + X86_MATCH_VFM(INTEL_ALDERLAKE_L, HYBRID_SCALING_FACTOR_ADL), + X86_MATCH_VFM(INTEL_RAPTORLAKE, HYBRID_SCALING_FACTOR_ADL), + X86_MATCH_VFM(INTEL_RAPTORLAKE_P, HYBRID_SCALING_FACTOR_ADL), + X86_MATCH_VFM(INTEL_RAPTORLAKE_S, HYBRID_SCALING_FACTOR_ADL), X86_MATCH_VFM(INTEL_METEORLAKE_L, HYBRID_SCALING_FACTOR_MTL), X86_MATCH_VFM(INTEL_ARROWLAKE, HYBRID_SCALING_FACTOR_MTL), X86_MATCH_VFM(INTEL_LUNARLAKE_M, HYBRID_SCALING_FACTOR_LNL), From patchwork Fri Nov 29 15:56:56 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Rafael J. Wysocki" X-Patchwork-Id: 846880 Received: from cloudserver094114.home.pl (cloudserver094114.home.pl [79.96.170.134]) (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 3FABC14831E; Fri, 29 Nov 2024 16:28:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=79.96.170.134 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732897710; cv=none; b=nND+XW8eoBfuotgbAC2Hm2CxnjYmD9Z2A+Qe8SOPv73U21n5ulvUyB5+P6tNJSCkd/xCSY9FJ/D0QbGttlxK/JPE4zb1C+pIWoomtFr4yMZ/Sj4MUX7u8Was4a2a6qnUrEXqUxGjnm12dq3HAjbopvAaZ81YZnm8NqQHI+Mw9ps= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732897710; c=relaxed/simple; bh=Yml7ibc3mhsE3NlB3vToy2x9i0cRBIbWozCgghBANps=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=bRXxRl0Fy1PIQPxeSWmFYW2NUwx5QW7fI1wgCOoYk+1RQg0LgBK6OhviNmgQ8basLY2HdLL12EuWjJ/l0ipVQCmbytzsM7jappp9HMoXC5nm2MPbVEw+ztumwQ5tfI3lLRVKuD0TDU37MvF3pBIHOiTVcS6hGoVv6mLBRogq0hQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rjwysocki.net; spf=pass smtp.mailfrom=rjwysocki.net; dkim=pass (2048-bit key) header.d=rjwysocki.net header.i=@rjwysocki.net header.b=Hywk+3eR; arc=none smtp.client-ip=79.96.170.134 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rjwysocki.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rjwysocki.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rjwysocki.net header.i=@rjwysocki.net header.b="Hywk+3eR" Received: from localhost (127.0.0.1) (HELO v370.home.net.pl) by /usr/run/smtp (/usr/run/postfix/private/idea_relay_lmtp) via UNIX with SMTP (IdeaSmtpServer 6.2.1) id 1a2f04069c1802b2; Fri, 29 Nov 2024 17:28:26 +0100 Received: from kreacher.localnet (unknown [195.136.19.94]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by cloudserver094114.home.pl (Postfix) with ESMTPSA id 9F0CCA47B8B; Fri, 29 Nov 2024 17:28:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rjwysocki.net; s=dkim; t=1732897706; bh=Yml7ibc3mhsE3NlB3vToy2x9i0cRBIbWozCgghBANps=; h=From:Subject:Date; b=Hywk+3eR5MKDhLcWm40yLSepsno+WLCarRsNvWO0NDS9GczLcwUHehhHrfuYviMYG 0TxD4YxZxoM18IHBvV5ihbq8oE5IfSEJ/MT7t6jjD4HwQxPwbyW1Th6r1pytwaycOm JvPcnN1CawL/g56pQOPJxRkerMHXUkX46wvwdMn67SPVgfJM8sgyKXX0QOiXM2BCFt k7rajdh4SPg8AYbxUMDqu1ZTex9Y4iZgJ6J1UtJNA7yD4Pc0wJp+aTv/SaHA23Ykdn XMf/30BTnW5+mm/zw9+g7zasYYJl1s3H964z2qBhAg4tKGHGzMqumRYM7mYdXf/J5K BZJkrJvfwH3mA== From: "Rafael J. Wysocki" To: Linux PM Cc: LKML , Lukasz Luba , Peter Zijlstra , Srinivas Pandruvada , Dietmar Eggemann , Morten Rasmussen , Vincent Guittot , Ricardo Neri , Pierre Gondois Subject: [RFC][PATCH v021 2/9] cpufreq: intel_pstate: Drop Arrow Lake from "scaling factor" list Date: Fri, 29 Nov 2024 16:56:56 +0100 Message-ID: <2372224.ElGaqSPkdT@rjwysocki.net> In-Reply-To: <5861970.DvuYhMxLoT@rjwysocki.net> References: <5861970.DvuYhMxLoT@rjwysocki.net> Precedence: bulk X-Mailing-List: linux-pm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-CLIENT-IP: 195.136.19.94 X-CLIENT-HOSTNAME: 195.136.19.94 X-VADE-SPAMSTATE: clean X-VADE-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefuddrheefgdekjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfjqffogffrnfdpggftiffpkfenuceurghilhhouhhtmecuudehtdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkjghfggfgtgesthfuredttddtjeenucfhrhhomhepfdftrghfrggvlhculfdrucghhihsohgtkhhifdcuoehrjhifsehrjhifhihsohgtkhhirdhnvghtqeenucggtffrrghtthgvrhhnpedvffeuiedtgfdvtddugeeujedtffetteegfeekffdvfedttddtuefhgeefvdejhfenucfkphepudelhedrudefiedrudelrdelgeenucevlhhushhtvghrufhiiigvpedunecurfgrrhgrmhepihhnvghtpeduleehrddufeeirdduledrleegpdhhvghlohepkhhrvggrtghhvghrrdhlohgtrghlnhgvthdpmhgrihhlfhhrohhmpehrjhifsehrjhifhihsohgtkhhirdhnvghtpdhnsggprhgtphhtthhopedutddprhgtphhtthhopehlihhnuhigqdhpmhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehluhhkrghsiidrlhhusggrsegrrhhmrdgtohhmpdhrtghpthhtohepphgvthgvrhiisehinhhfrhgruggvrggurdhorhhgpdhrtghpthhtohepshhrihhnihhvrghsrdhprghnughruhhvrggurgeslhhinhhugidrihhnthg X-DCC--Metrics: v370.home.net.pl 1024; Body=10 Fuz1=10 Fuz2=10 From: Rafael J. Wysocki Since HYBRID_SCALING_FACTOR_MTL is not going to be suitable for Arrow Lake in general, drop it from the "hybrid scaling factor" list of platforms, so the scaling factor for it will be determined with the help of information provided by the platform firmware via CPPC. Signed-off-by: Rafael J. Wysocki --- drivers/cpufreq/intel_pstate.c | 1 - 1 file changed, 1 deletion(-) Index: linux-pm/drivers/cpufreq/intel_pstate.c =================================================================== --- linux-pm.orig/drivers/cpufreq/intel_pstate.c +++ linux-pm/drivers/cpufreq/intel_pstate.c @@ -3675,7 +3675,6 @@ static const struct x86_cpu_id intel_hyb X86_MATCH_VFM(INTEL_RAPTORLAKE_P, HYBRID_SCALING_FACTOR_ADL), X86_MATCH_VFM(INTEL_RAPTORLAKE_S, HYBRID_SCALING_FACTOR_ADL), X86_MATCH_VFM(INTEL_METEORLAKE_L, HYBRID_SCALING_FACTOR_MTL), - X86_MATCH_VFM(INTEL_ARROWLAKE, HYBRID_SCALING_FACTOR_MTL), X86_MATCH_VFM(INTEL_LUNARLAKE_M, HYBRID_SCALING_FACTOR_LNL), {} }; From patchwork Fri Nov 29 15:59:06 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Rafael J. Wysocki" X-Patchwork-Id: 846881 Received: from cloudserver094114.home.pl (cloudserver094114.home.pl [79.96.170.134]) (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 4B86945BEC; Fri, 29 Nov 2024 16:28:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=79.96.170.134 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732897710; cv=none; b=GzbJOxGbps5bKySt1O2xoGEpsWCZjoUgww8fjEUcqAkJAaMxFGlA/H1XByptJgTMA7dJs7EHsVa5Ec0Vownf1ZIugWaB5thZQylBOmIdpLJ85X+a+FhC0hM3zC89LZ6dMnNetzapCy8iQWI70OaPDIMfjJ93OGFOk0F8gKyEjFw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732897710; c=relaxed/simple; bh=70VAqg/TQpJWDE7ktXbJySBPdaEm0FcPRiLHVS6/0Qg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=a43uMvjFjt+77QgHcBaOdFQD6g8fbejWV20A8fJD8VFwPHiT8zbu4XqTqoZQx6R1BeHN7826yni2JCQg61jMlbDVPynmodUlg0eBglkPrakb0dSrLyoOFmHdU6WUwQR58YPzvk+eWPZNnlVKZmZWcRAbfTJKNx7o5+WRoi9hHjk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rjwysocki.net; spf=pass smtp.mailfrom=rjwysocki.net; dkim=pass (2048-bit key) header.d=rjwysocki.net header.i=@rjwysocki.net header.b=n7H/4bF/; arc=none smtp.client-ip=79.96.170.134 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rjwysocki.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rjwysocki.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rjwysocki.net header.i=@rjwysocki.net header.b="n7H/4bF/" Received: from localhost (127.0.0.1) (HELO v370.home.net.pl) by /usr/run/smtp (/usr/run/postfix/private/idea_relay_lmtp) via UNIX with SMTP (IdeaSmtpServer 6.2.1) id 7508729bf5dc54a4; Fri, 29 Nov 2024 17:28:25 +0100 Received: from kreacher.localnet (unknown [195.136.19.94]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by cloudserver094114.home.pl (Postfix) with ESMTPSA id AEE1EA47B8B; Fri, 29 Nov 2024 17:28:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rjwysocki.net; s=dkim; t=1732897705; bh=70VAqg/TQpJWDE7ktXbJySBPdaEm0FcPRiLHVS6/0Qg=; h=From:Subject:Date; b=n7H/4bF/KpSAS8A7lDXbh/Z9QenT9BYexxAzDsH4X25avSJLAiTJxIt7NCSiIgTgK gp77dfDRcxrMmve7slXtGSxW/fiJahZyPocChSqhT50bLQTA2070PfQNU/EGwHRDyf 11xJ+jRecbASE6OAaUUF39aUx+w1wLa8ffnHyfvqKQJkiYXEBaKOGblXXUdNDZpyTQ WFTNNZxIh2l5VOvkW2czfHGiUe7Ez57ymIaanhWjiDZpnESB++XvefftJsfmtFG/ho yTReavoW7LGrpp2VQ5W7lFD9kijnzw4g4L3mq9/9d7yMrlUju589wGEiZwh6ffqOpb rqaqZLKj6SDiA== From: "Rafael J. Wysocki" To: Linux PM Cc: LKML , Lukasz Luba , Peter Zijlstra , Srinivas Pandruvada , Dietmar Eggemann , Morten Rasmussen , Vincent Guittot , Ricardo Neri , Pierre Gondois Subject: [RFC][PATCH v021 3/9] PM: EM: Move perf rebuilding function from schedutil to EM Date: Fri, 29 Nov 2024 16:59:06 +0100 Message-ID: <2229205.irdbgypaU6@rjwysocki.net> In-Reply-To: <5861970.DvuYhMxLoT@rjwysocki.net> References: <5861970.DvuYhMxLoT@rjwysocki.net> Precedence: bulk X-Mailing-List: linux-pm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-CLIENT-IP: 195.136.19.94 X-CLIENT-HOSTNAME: 195.136.19.94 X-VADE-SPAMSTATE: clean X-VADE-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefuddrheefgdekjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfjqffogffrnfdpggftiffpkfenuceurghilhhouhhtmecuudehtdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkjghfggfgtgesthfuredttddtjeenucfhrhhomhepfdftrghfrggvlhculfdrucghhihsohgtkhhifdcuoehrjhifsehrjhifhihsohgtkhhirdhnvghtqeenucggtffrrghtthgvrhhnpedvffeuiedtgfdvtddugeeujedtffetteegfeekffdvfedttddtuefhgeefvdejhfenucfkphepudelhedrudefiedrudelrdelgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduleehrddufeeirdduledrleegpdhhvghlohepkhhrvggrtghhvghrrdhlohgtrghlnhgvthdpmhgrihhlfhhrohhmpehrjhifsehrjhifhihsohgtkhhirdhnvghtpdhnsggprhgtphhtthhopedutddprhgtphhtthhopehlihhnuhigqdhpmhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehluhhkrghsiidrlhhusggrsegrrhhmrdgtohhmpdhrtghpthhtohepphgvthgvrhiisehinhhfrhgruggvrggurdhorhhgpdhrtghpthhtohepshhrihhnihhvrghsrdhprghnughruhhvrggurgeslhhinhhugidrihhnthg X-DCC--Metrics: v370.home.net.pl 1024; Body=10 Fuz1=10 Fuz2=10 From: Rafael J. Wysocki The sugov_eas_rebuild_sd() function defined in the schedutil cpufreq governor implements generic functionality that may be useful in other places. In particular, going forward it will be used in the intel_pstate driver. For this reason, move it from schedutil to the energy model code and rename it to em_rebuild_perf_domains(). This also helps to get rid of some #ifdeffery in schedutil which is a plus. No intentional functional impact. Signed-off-by: Rafael J. Wysocki --- v0.1 -> v0.2: * Update the comment regarding :register_em() in cpufreq. * Changelog edits. --- drivers/cpufreq/cpufreq.c | 2 +- include/linux/energy_model.h | 2 ++ kernel/power/energy_model.c | 17 +++++++++++++++++ kernel/sched/cpufreq_schedutil.c | 33 ++++++--------------------------- 4 files changed, 26 insertions(+), 28 deletions(-) Index: linux-pm/kernel/power/energy_model.c =================================================================== --- linux-pm.orig/kernel/power/energy_model.c +++ linux-pm/kernel/power/energy_model.c @@ -908,3 +908,20 @@ int em_update_performance_limits(struct return 0; } EXPORT_SYMBOL_GPL(em_update_performance_limits); + +static void rebuild_sd_workfn(struct work_struct *work) +{ + rebuild_sched_domains_energy(); +} + +static DECLARE_WORK(rebuild_sd_work, rebuild_sd_workfn); + +void em_rebuild_perf_domains(void) +{ + /* + * When called from the cpufreq_register_driver() path, the + * cpu_hotplug_lock is already held, so use a work item to + * avoid nested locking in rebuild_sched_domains(). + */ + schedule_work(&rebuild_sd_work); +} Index: linux-pm/kernel/sched/cpufreq_schedutil.c =================================================================== --- linux-pm.orig/kernel/sched/cpufreq_schedutil.c +++ linux-pm/kernel/sched/cpufreq_schedutil.c @@ -604,31 +604,6 @@ static const struct kobj_type sugov_tuna /********************** cpufreq governor interface *********************/ -#ifdef CONFIG_ENERGY_MODEL -static void rebuild_sd_workfn(struct work_struct *work) -{ - rebuild_sched_domains_energy(); -} - -static DECLARE_WORK(rebuild_sd_work, rebuild_sd_workfn); - -/* - * EAS shouldn't be attempted without sugov, so rebuild the sched_domains - * on governor changes to make sure the scheduler knows about it. - */ -static void sugov_eas_rebuild_sd(void) -{ - /* - * When called from the cpufreq_register_driver() path, the - * cpu_hotplug_lock is already held, so use a work item to - * avoid nested locking in rebuild_sched_domains(). - */ - schedule_work(&rebuild_sd_work); -} -#else -static inline void sugov_eas_rebuild_sd(void) { }; -#endif - struct cpufreq_governor schedutil_gov; static struct sugov_policy *sugov_policy_alloc(struct cpufreq_policy *policy) @@ -784,7 +759,11 @@ static int sugov_init(struct cpufreq_pol goto fail; out: - sugov_eas_rebuild_sd(); + /* + * EAS shouldn't be attempted without sugov, so rebuild the sched_domains + * on governor changes to make sure the scheduler knows about them. + */ + em_rebuild_perf_domains(); mutex_unlock(&global_tunables_lock); return 0; @@ -826,7 +805,7 @@ static void sugov_exit(struct cpufreq_po sugov_policy_free(sg_policy); cpufreq_disable_fast_switch(policy); - sugov_eas_rebuild_sd(); + em_rebuild_perf_domains(); } static int sugov_start(struct cpufreq_policy *policy) Index: linux-pm/include/linux/energy_model.h =================================================================== --- linux-pm.orig/include/linux/energy_model.h +++ linux-pm/include/linux/energy_model.h @@ -179,6 +179,7 @@ int em_dev_compute_costs(struct device * int em_dev_update_chip_binning(struct device *dev); int em_update_performance_limits(struct em_perf_domain *pd, unsigned long freq_min_khz, unsigned long freq_max_khz); +void em_rebuild_perf_domains(void); /** * em_pd_get_efficient_state() - Get an efficient performance state from the EM @@ -404,6 +405,7 @@ int em_update_performance_limits(struct { return -EINVAL; } +static inline void em_rebuild_perf_domains(void) {} #endif #endif Index: linux-pm/drivers/cpufreq/cpufreq.c =================================================================== --- linux-pm.orig/drivers/cpufreq/cpufreq.c +++ linux-pm/drivers/cpufreq/cpufreq.c @@ -1538,7 +1538,7 @@ static int cpufreq_online(unsigned int c /* * Register with the energy model before - * sugov_eas_rebuild_sd() is called, which will result + * em_rebuild_perf_domains() is called, which will result * in rebuilding of the sched domains, which should only be done * once the energy model is properly initialized for the policy * first. From patchwork Fri Nov 29 16:00:59 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Rafael J. Wysocki" X-Patchwork-Id: 846232 Received: from cloudserver094114.home.pl (cloudserver094114.home.pl [79.96.170.134]) (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 B3DEE19F487; Fri, 29 Nov 2024 16:28:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=79.96.170.134 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732897713; cv=none; b=V4tZNyQtrjHHgMQ0kR5XndtenMZz4lOE+35fZQlRZsIoap4+2Xf3Zc9c8mnGfr6HnDqzYaeknXsratYKWZ9dhKohV08Qk89Vo8AGFFerS0z214DHUKoqPtPwt9+0Wj5VKEBM+34OSLdVwQWIeHXzcp+A8sh4Vx+6Hggd4KqvVfQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732897713; c=relaxed/simple; bh=DvLkM9d0KNOiudzMFfjoKtE0E+UoCa929oHu3SnD37M=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=bDyQH4JdnytJrIsKARz3ON6kYVfG52kCx2RJfNvbbSzTqbi17KV0WFmLcJ3hR1kFBhiuRFxg2ECP43F71j/Klwn5SFgkppoR4ntEp1yRE0divlFInAsgw8PqDO03TseGVHL7HOmXGReCLWSa5Uwmoxqh13vbPUFpnbKAEd7T2S8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rjwysocki.net; spf=pass smtp.mailfrom=rjwysocki.net; dkim=pass (2048-bit key) header.d=rjwysocki.net header.i=@rjwysocki.net header.b=uqdnLilb; arc=none smtp.client-ip=79.96.170.134 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rjwysocki.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rjwysocki.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rjwysocki.net header.i=@rjwysocki.net header.b="uqdnLilb" Received: from localhost (127.0.0.1) (HELO v370.home.net.pl) by /usr/run/smtp (/usr/run/postfix/private/idea_relay_lmtp) via UNIX with SMTP (IdeaSmtpServer 6.2.1) id 9c19526eca5e3f77; Fri, 29 Nov 2024 17:28:24 +0100 Received: from kreacher.localnet (unknown [195.136.19.94]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by cloudserver094114.home.pl (Postfix) with ESMTPSA id CDA8BA47B8B; Fri, 29 Nov 2024 17:28:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rjwysocki.net; s=dkim; t=1732897704; bh=DvLkM9d0KNOiudzMFfjoKtE0E+UoCa929oHu3SnD37M=; h=From:Subject:Date; b=uqdnLilbd66jLccEp56jTtqWkpNdifnu97jfpKjw1rVwmTZ5kySK3Xyc8mJK+f9or fKppbAvNGrrx0jZMuqs39/QkFxgTuzfeY3YTQ+wyqAfYw8edFHOVP0rCnDMaRqfo8c F8RpL07GaHEEzEiFguVQBElos5iLZSlDmMuUzpMwxUMXa+6YOiSOuioDzqYwLtsu5y 8cDPSYpqtzrzGlU3ICTEmkpTgmuD77UBaXD4nARARd97lARx2rFN89iiVInYMIm3jn 2zk1Gj3ZHU+mDhiMK3XFJTEXgt4eigzA63aAUnvL0hRMbHNpSr9AV5McDdx6ixTZ61 ZQ4aYqS3H6Nlw== From: "Rafael J. Wysocki" To: Linux PM Cc: LKML , Lukasz Luba , Peter Zijlstra , Srinivas Pandruvada , Dietmar Eggemann , Morten Rasmussen , Vincent Guittot , Ricardo Neri , Pierre Gondois Subject: [RFC][PATCH v021 4/9] sched/topology: Adjust cpufreq checks for EAS Date: Fri, 29 Nov 2024 17:00:59 +0100 Message-ID: <2989520.e9J7NaK4W3@rjwysocki.net> In-Reply-To: <5861970.DvuYhMxLoT@rjwysocki.net> References: <5861970.DvuYhMxLoT@rjwysocki.net> Precedence: bulk X-Mailing-List: linux-pm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-CLIENT-IP: 195.136.19.94 X-CLIENT-HOSTNAME: 195.136.19.94 X-VADE-SPAMSTATE: clean X-VADE-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefuddrheefgdekjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfjqffogffrnfdpggftiffpkfenuceurghilhhouhhtmecuudehtdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkjghfggfgtgesthfuredttddtjeenucfhrhhomhepfdftrghfrggvlhculfdrucghhihsohgtkhhifdcuoehrjhifsehrjhifhihsohgtkhhirdhnvghtqeenucggtffrrghtthgvrhhnpedvffeuiedtgfdvtddugeeujedtffetteegfeekffdvfedttddtuefhgeefvdejhfenucfkphepudelhedrudefiedrudelrdelgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduleehrddufeeirdduledrleegpdhhvghlohepkhhrvggrtghhvghrrdhlohgtrghlnhgvthdpmhgrihhlfhhrohhmpehrjhifsehrjhifhihsohgtkhhirdhnvghtpdhnsggprhgtphhtthhopedutddprhgtphhtthhopehlihhnuhigqdhpmhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehluhhkrghsiidrlhhusggrsegrrhhmrdgtohhmpdhrtghpthhtohepphgvthgvrhiisehinhhfrhgruggvrggurdhorhhgpdhrtghpthhtohepshhrihhnihhvrghsrdhprghnughruhhvrggurgeslhhinhhugidrihhnthg X-DCC--Metrics: v370.home.net.pl 1024; Body=10 Fuz1=10 Fuz2=10 From: Rafael J. Wysocki Make it possible to use EAS with cpufreq drivers that implement the :setpolicy() callback instead of using generic cpufreq governors. This is going to be necessary for using EAS with intel_pstate in its default configuration. Signed-off-by: Rafael J. Wysocki --- This is the minimum of what's needed, but I'd really prefer to move the cpufreq vs EAS checks into cpufreq because messing around cpufreq internals in topology.c feels like a butcher shop kind of exercise. Besides, as I said before, I remain unconvinced about the usefulness of these checks at all. Yes, one is supposed to get the best results from EAS when running schedutil, but what if they just want to try something else with EAS? What if they can get better results with that other thing, surprisingly enough? --- kernel/sched/topology.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) Index: linux-pm/kernel/sched/topology.c =================================================================== --- linux-pm.orig/kernel/sched/topology.c +++ linux-pm/kernel/sched/topology.c @@ -217,6 +217,7 @@ static bool sched_is_eas_possible(const bool any_asym_capacity = false; struct cpufreq_policy *policy; struct cpufreq_governor *gov; + bool cpufreq_ok; int i; /* EAS is enabled for asymmetric CPU capacity topologies. */ @@ -251,7 +252,7 @@ static bool sched_is_eas_possible(const return false; } - /* Do not attempt EAS if schedutil is not being used. */ + /* Do not attempt EAS if cpufreq is not configured adequately */ for_each_cpu(i, cpu_mask) { policy = cpufreq_cpu_get(i); if (!policy) { @@ -261,11 +262,14 @@ static bool sched_is_eas_possible(const } return false; } + /* Require schedutil or a "setpolicy" driver */ gov = policy->governor; + cpufreq_ok = gov == &schedutil_gov || + (!gov && policy->policy != CPUFREQ_POLICY_UNKNOWN); cpufreq_cpu_put(policy); - if (gov != &schedutil_gov) { + if (!cpufreq_ok) { if (sched_debug()) { - pr_info("rd %*pbl: Checking EAS, schedutil is mandatory\n", + pr_info("rd %*pbl: Checking EAS, unsuitable cpufreq governor\n", cpumask_pr_args(cpu_mask)); } return false; From patchwork Fri Nov 29 16:02:02 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Rafael J. Wysocki" X-Patchwork-Id: 846233 Received: from cloudserver094114.home.pl (cloudserver094114.home.pl [79.96.170.134]) (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 BAA6319CC02; Fri, 29 Nov 2024 16:28:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=79.96.170.134 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732897712; cv=none; b=rdp0msrIp/MLdt+Ujy5qByQ6RcFFjGX9bnIYFUb+O72b/utiBZ4HoPjg7sOgKoKQMvfZ8k/0LSJ+64fUd+bR04SEQ9HZyTUJ4JbH3CFk18Ey/O7DdZ/2WjmY0qF26I/Aup6y1a8a8tQOzK4dSNmZUWug7DMj+RhavlyLZEGI8CY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732897712; c=relaxed/simple; bh=wMEd2h7OudxO2dV+sTCknQbfUGqj+8oLnQbaSw+jLb0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=EJPrdy2zk9jPk2orWSyzV7eBw1UiY5k1K+l19ZQS6YdOQoFyfAnPpl3tROORVOPAKqGEBTHaoZbNkKpFwIar9dLcqzd/+mwVOHAazkYMARgYgKAXpCw7yf7dZSwYr+Fn43lm5apjczZezDJPtS4xVFrgfOPmRRyfcAOPsYqKh5A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rjwysocki.net; spf=pass smtp.mailfrom=rjwysocki.net; dkim=pass (2048-bit key) header.d=rjwysocki.net header.i=@rjwysocki.net header.b=UI2HNgbG; arc=none smtp.client-ip=79.96.170.134 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rjwysocki.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rjwysocki.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rjwysocki.net header.i=@rjwysocki.net header.b="UI2HNgbG" Received: from localhost (127.0.0.1) (HELO v370.home.net.pl) by /usr/run/smtp (/usr/run/postfix/private/idea_relay_lmtp) via UNIX with SMTP (IdeaSmtpServer 6.2.1) id 2c1251ab29003005; Fri, 29 Nov 2024 17:28:23 +0100 Received: from kreacher.localnet (unknown [195.136.19.94]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by cloudserver094114.home.pl (Postfix) with ESMTPSA id E697EA47B8B; Fri, 29 Nov 2024 17:28:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rjwysocki.net; s=dkim; t=1732897703; bh=wMEd2h7OudxO2dV+sTCknQbfUGqj+8oLnQbaSw+jLb0=; h=From:Subject:Date; b=UI2HNgbGTg30pamLeA7Hsr7h4WYRqDVBjilad9oCD3WQ78x69MuC0MjbNj/XjphdW 7E5fDZBcFaU1oSeNbfxaUiOhAaZiF1uSLLV6aaxAveZD3sG8SDE9WPDJaa2kNb6DW8 eBoNycHbR2A/tWIaiHuWGNWn8YnivEXtQgmZgUrlON8u52Vitf1XPh608M/WsR6Okt r+gLwLLbS3J1ci8gtaB6v5TrlUOlU2RYCIy0/XmxfzLjNJfCH15G4n6jvOW0mvFJkl AoMaHka/V25u6sYCP4rj9Ir8akmS9L2/ZqHD9DVV/NUCgbokqioDW0gPmGNGD8FoRH V7oFXb+q9sZpg== From: "Rafael J. Wysocki" To: Linux PM Cc: LKML , Lukasz Luba , Peter Zijlstra , Srinivas Pandruvada , Dietmar Eggemann , Morten Rasmussen , Vincent Guittot , Ricardo Neri , Pierre Gondois Subject: [RFC][PATCH v021 5/9] PM: EM: Introduce em_dev_expand_perf_domain() Date: Fri, 29 Nov 2024 17:02:02 +0100 Message-ID: <3353401.44csPzL39Z@rjwysocki.net> In-Reply-To: <5861970.DvuYhMxLoT@rjwysocki.net> References: <5861970.DvuYhMxLoT@rjwysocki.net> Precedence: bulk X-Mailing-List: linux-pm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-CLIENT-IP: 195.136.19.94 X-CLIENT-HOSTNAME: 195.136.19.94 X-VADE-SPAMSTATE: clean X-VADE-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefuddrheefgdekjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfjqffogffrnfdpggftiffpkfenuceurghilhhouhhtmecuudehtdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkjghfggfgtgesthfuredttddtjeenucfhrhhomhepfdftrghfrggvlhculfdrucghhihsohgtkhhifdcuoehrjhifsehrjhifhihsohgtkhhirdhnvghtqeenucggtffrrghtthgvrhhnpedvffeuiedtgfdvtddugeeujedtffetteegfeekffdvfedttddtuefhgeefvdejhfenucfkphepudelhedrudefiedrudelrdelgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduleehrddufeeirdduledrleegpdhhvghlohepkhhrvggrtghhvghrrdhlohgtrghlnhgvthdpmhgrihhlfhhrohhmpehrjhifsehrjhifhihsohgtkhhirdhnvghtpdhnsggprhgtphhtthhopedutddprhgtphhtthhopehlihhnuhigqdhpmhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehluhhkrghsiidrlhhusggrsegrrhhmrdgtohhmpdhrtghpthhtohepphgvthgvrhiisehinhhfrhgruggvrggurdhorhhgpdhrtghpthhtohepshhrihhnihhvrghsrdhprghnughruhhvrggurgeslhhinhhugidrihhnthg X-DCC--Metrics: v370.home.net.pl 1024; Body=10 Fuz1=10 Fuz2=10 From: Rafael J. Wysocki Introduce a helper function for adding a CPU to an existing EM perf domain. Subsequently, this will be used by the intel_pstate driver to add new CPUs to existing perf domains when those CPUs go online for the first time after the initialization of the driver. No intentional functional impact. Signed-off-by: Rafael J. Wysocki --- v0.1 -> v0.2: No changes --- include/linux/energy_model.h | 5 +++++ kernel/power/energy_model.c | 32 ++++++++++++++++++++++++++++++++ 2 files changed, 37 insertions(+) Index: linux-pm/kernel/power/energy_model.c =================================================================== --- linux-pm.orig/kernel/power/energy_model.c +++ linux-pm/kernel/power/energy_model.c @@ -676,6 +676,38 @@ void em_dev_unregister_perf_domain(struc } EXPORT_SYMBOL_GPL(em_dev_unregister_perf_domain); +/** + * em_dev_expand_perf_domain() - Expand CPU perf domain + * @dev: CPU device of a CPU in the perf domain. + * @new_cpu: CPU to add to the perf domain. + */ +int em_dev_expand_perf_domain(struct device *dev, int new_cpu) +{ + struct device *new_cpu_dev; + struct em_perf_domain *pd; + + if (IS_ERR_OR_NULL(dev) || !_is_cpu_device(dev)) + return -EINVAL; + + new_cpu_dev = get_cpu_device(new_cpu); + if (!new_cpu_dev) + return -EINVAL; + + guard(mutex)(&em_pd_mutex); + + if (em_pd_get(new_cpu_dev)) + return -EEXIST; + + pd = em_pd_get(dev); + if (!pd) + return -EINVAL; + + cpumask_set_cpu(new_cpu, em_span_cpus(pd)); + new_cpu_dev->em_pd = pd; + + return 0; +} + static struct em_perf_table __rcu *em_table_dup(struct em_perf_domain *pd) { struct em_perf_table __rcu *em_table; Index: linux-pm/include/linux/energy_model.h =================================================================== --- linux-pm.orig/include/linux/energy_model.h +++ linux-pm/include/linux/energy_model.h @@ -172,6 +172,7 @@ int em_dev_register_perf_domain(struct d struct em_data_callback *cb, cpumask_t *span, bool microwatts); void em_dev_unregister_perf_domain(struct device *dev); +int em_dev_expand_perf_domain(struct device *dev, int new_cpu); struct em_perf_table __rcu *em_table_alloc(struct em_perf_domain *pd); void em_table_free(struct em_perf_table __rcu *table); int em_dev_compute_costs(struct device *dev, struct em_perf_state *table, @@ -354,6 +355,10 @@ int em_dev_register_perf_domain(struct d static inline void em_dev_unregister_perf_domain(struct device *dev) { } +static inline int em_dev_expand_perf_domain(struct device *dev, int new_cpu) +{ + return -EINVAL; +} static inline struct em_perf_domain *em_cpu_get(int cpu) { return NULL; From patchwork Fri Nov 29 16:06:52 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Rafael J. Wysocki" X-Patchwork-Id: 846878 Received: from cloudserver094114.home.pl (cloudserver094114.home.pl [79.96.170.134]) (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 EC44414F9F9; Fri, 29 Nov 2024 16:28:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=79.96.170.134 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732897712; cv=none; b=eaQJpNplpnlyJe+U6eWRkUeUPNjV//0pEv+sKxuJMzVe9pBJbnJ4xwWEFZ6O+FNlDOlQoFWfllSRv7dXx39zyStL2GwKH+7TEtxKWLdG32M0hGJj1uv6LkspViuC++OYTZJ+UkWKojulY0uKWAV1PRCh9imEzXmiAN9p0wDUVi8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732897712; c=relaxed/simple; bh=CoHMWva7c4OBH0vaKdTvFtpcFV5sbCOP/HbkqDCr2Vw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=sSLNKzWZLLhGrjBOtxPvdUGadC3lQKRJMYMSbyaTevHgKs0iK+3fYHZCQtaaq6AsnkTQhlOlaV+FXSzbIk7AmnaZHcEn/u37+4URss9nBc+bR6UFsW0law/yCQTqt0KeUcsJCgqRBuG0/WuPg6PAWd4vbiQkMP23LCqTBbgGFOg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rjwysocki.net; spf=pass smtp.mailfrom=rjwysocki.net; dkim=pass (2048-bit key) header.d=rjwysocki.net header.i=@rjwysocki.net header.b=c2ed2Rff; arc=none smtp.client-ip=79.96.170.134 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rjwysocki.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rjwysocki.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rjwysocki.net header.i=@rjwysocki.net header.b="c2ed2Rff" Received: from localhost (127.0.0.1) (HELO v370.home.net.pl) by /usr/run/smtp (/usr/run/postfix/private/idea_relay_lmtp) via UNIX with SMTP (IdeaSmtpServer 6.2.1) id 9c33acf31241bace; Fri, 29 Nov 2024 17:28:22 +0100 Received: from kreacher.localnet (unknown [195.136.19.94]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by cloudserver094114.home.pl (Postfix) with ESMTPSA id C2718A47B8C; Fri, 29 Nov 2024 17:28:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rjwysocki.net; s=dkim; t=1732897702; bh=CoHMWva7c4OBH0vaKdTvFtpcFV5sbCOP/HbkqDCr2Vw=; h=From:Subject:Date; b=c2ed2RffCGnatxCZCe71yEGTndSOihyIqjmIl2FmrWtkAGDJCa9K51FFGD/SA7S3Y 8GRSyBopH/eUp9rOWhLXM/wM+U1RSU5OrZkhkGBmGfJTcY2LZWzhnbz9RtrhDFzn+m Zd0a5UioeZWadeQckotiJfmfYav0x87Z9jZwRKFNqSoXssZFt4r0t3sN74SddoAt1p JYV/QuGn9s7UrbddDfF6N4vWutSqVztUsk6v5d+xJ1y2kMcQw9LabNXgXapiuUUziP hBtJJGZY6b4S7OIUlkiWAYDytlROhzYkot+GjEP7BpK+iNkSGt3FAaab3Yu+9OjfOe E7XQWsY/94d+Q== From: "Rafael J. Wysocki" To: Linux PM Cc: LKML , Lukasz Luba , Peter Zijlstra , Srinivas Pandruvada , Dietmar Eggemann , Morten Rasmussen , Vincent Guittot , Ricardo Neri , Pierre Gondois Subject: [RFC][PATCH v021 6/9] PM: EM: Call em_compute_costs() from em_create_perf_table() Date: Fri, 29 Nov 2024 17:06:52 +0100 Message-ID: <2010024.PYKUYFuaPT@rjwysocki.net> In-Reply-To: <5861970.DvuYhMxLoT@rjwysocki.net> References: <5861970.DvuYhMxLoT@rjwysocki.net> Precedence: bulk X-Mailing-List: linux-pm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-CLIENT-IP: 195.136.19.94 X-CLIENT-HOSTNAME: 195.136.19.94 X-VADE-SPAMSTATE: clean X-VADE-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefuddrheefgdekjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfjqffogffrnfdpggftiffpkfenuceurghilhhouhhtmecuudehtdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkjghfggfgtgesthfuredttddtjeenucfhrhhomhepfdftrghfrggvlhculfdrucghhihsohgtkhhifdcuoehrjhifsehrjhifhihsohgtkhhirdhnvghtqeenucggtffrrghtthgvrhhnpedvffeuiedtgfdvtddugeeujedtffetteegfeekffdvfedttddtuefhgeefvdejhfenucfkphepudelhedrudefiedrudelrdelgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduleehrddufeeirdduledrleegpdhhvghlohepkhhrvggrtghhvghrrdhlohgtrghlnhgvthdpmhgrihhlfhhrohhmpehrjhifsehrjhifhihsohgtkhhirdhnvghtpdhnsggprhgtphhtthhopedutddprhgtphhtthhopehlihhnuhigqdhpmhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehluhhkrghsiidrlhhusggrsegrrhhmrdgtohhmpdhrtghpthhtohepphgvthgvrhiisehinhhfrhgruggvrggurdhorhhgpdhrtghpthhtohepshhrihhnihhvrghsrdhprghnughruhhvrggurgeslhhinhhugidrihhnthg X-DCC--Metrics: v370.home.net.pl 1024; Body=10 Fuz1=10 Fuz2=10 From: Rafael J. Wysocki In preparation for subsequent changes, move the em_compute_costs() invocation from em_create_perf_table() to em_create_pd() which is its only caller. This helps to prepare the EM registration code for handling the case in which the :active_power() EM callback is NULL. No intentional functional impact. Signed-off-by: Rafael J. Wysocki --- v0.1 -> v0.2: Update changelog to explain what subsequent change depends on this patch. --- kernel/power/energy_model.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) Index: linux-pm/kernel/power/energy_model.c =================================================================== --- linux-pm.orig/kernel/power/energy_model.c +++ linux-pm/kernel/power/energy_model.c @@ -388,10 +388,6 @@ static int em_create_perf_table(struct d em_init_performance(dev, pd, table, nr_states); - ret = em_compute_costs(dev, table, cb, nr_states, flags); - if (ret) - return -EINVAL; - return 0; } @@ -434,6 +430,10 @@ static int em_create_pd(struct device *d if (ret) goto free_pd_table; + ret = em_compute_costs(dev, em_table->state, cb, nr_states, flags); + if (ret) + goto free_pd_table; + rcu_assign_pointer(pd->em_table, em_table); if (_is_cpu_device(dev)) From patchwork Fri Nov 29 16:15:45 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Rafael J. Wysocki" X-Patchwork-Id: 846879 Received: from cloudserver094114.home.pl (cloudserver094114.home.pl [79.96.170.134]) (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 E489D14C5B3; Fri, 29 Nov 2024 16:28:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=79.96.170.134 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732897711; cv=none; b=McruElrG1nyD4qqTqXNeN7xj2el/kFSgNJ4RLHfJlL3lXqzj768Ko7tfnLwkf2gHd3EL1RIIshM1YbxgVJwgKugziHkx/1SfRXJsCrPtV8YnuprAGifiuvD+1wlGkU4wx5duXDhzTHVSbgh/Ygxfr/QXixXxJFNpHeC/v7XmQq4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732897711; c=relaxed/simple; bh=OYoXq9Htw15pDNwhKe3wmKi9nfDTgqvonQ9dTbuSg84=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=YOhYPIr40MFmlcX9VcHMXfFdn50SbYfebkApmPCiUYROzGiXkO5RvRruSZ8pzto4ptSIBI6Udd7FS87OnD3ZWXfNJ6Cz6TdGeEt0r6NsCH2M/uKHA8h345mzyohcAvxJjNTeMnxUbs/8dbpqDQTrKwN481Lt7oCy6XdVOZPndjs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rjwysocki.net; spf=pass smtp.mailfrom=rjwysocki.net; dkim=pass (2048-bit key) header.d=rjwysocki.net header.i=@rjwysocki.net header.b=iyxU5GY/; arc=none smtp.client-ip=79.96.170.134 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rjwysocki.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rjwysocki.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rjwysocki.net header.i=@rjwysocki.net header.b="iyxU5GY/" Received: from localhost (127.0.0.1) (HELO v370.home.net.pl) by /usr/run/smtp (/usr/run/postfix/private/idea_relay_lmtp) via UNIX with SMTP (IdeaSmtpServer 6.2.1) id 5f518de4bde3e1e6; Fri, 29 Nov 2024 17:28:21 +0100 Received: from kreacher.localnet (unknown [195.136.19.94]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by cloudserver094114.home.pl (Postfix) with ESMTPSA id D5E56A47B8B; Fri, 29 Nov 2024 17:28:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rjwysocki.net; s=dkim; t=1732897701; bh=OYoXq9Htw15pDNwhKe3wmKi9nfDTgqvonQ9dTbuSg84=; h=From:Subject:Date; b=iyxU5GY/ArKuU8HnZM+epBBnOro2bqsKPxWgzpzvZ8DNMNQFXXjnKY7X9OfmRwZrD 2bOAQpi+XKBLJqrdArSchnvurDoSO19PUpBuNjoi822povcdACcdRuddwJIphl7PDj I1inSGuwhLDpRZngzTRwi05TL6nEVzTq1IxE+3jag6g4UrrW7uanGig/2S88LlP1jZ 2a2Tdteh51I4/uVWWBtKF9KQgZY1RrCXI83NJ59CZZ87Vkpc3cewxr9Q6d6G8+/iDc +ESxhmkK76AxPu1PX+jHGVyFUOeENO8jvDPYv2OZw8q7gsLQQpMaJBLySnVVNl+nfw S4y/vzxX4XGeQ== From: "Rafael J. Wysocki" To: Linux PM Cc: LKML , Lukasz Luba , Peter Zijlstra , Srinivas Pandruvada , Dietmar Eggemann , Morten Rasmussen , Vincent Guittot , Ricardo Neri , Pierre Gondois Subject: [RFC][PATCH v021 7/9] PM: EM: Register perf domains with ho :active_power() callbacks Date: Fri, 29 Nov 2024 17:15:45 +0100 Message-ID: <3278518.5fSG56mABF@rjwysocki.net> In-Reply-To: <5861970.DvuYhMxLoT@rjwysocki.net> References: <5861970.DvuYhMxLoT@rjwysocki.net> Precedence: bulk X-Mailing-List: linux-pm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-CLIENT-IP: 195.136.19.94 X-CLIENT-HOSTNAME: 195.136.19.94 X-VADE-SPAMSTATE: clean X-VADE-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefuddrheefgdekjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfjqffogffrnfdpggftiffpkfenuceurghilhhouhhtmecuudehtdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkjghfggfgtgesthfuredttddtjeenucfhrhhomhepfdftrghfrggvlhculfdrucghhihsohgtkhhifdcuoehrjhifsehrjhifhihsohgtkhhirdhnvghtqeenucggtffrrghtthgvrhhnpedvffeuiedtgfdvtddugeeujedtffetteegfeekffdvfedttddtuefhgeefvdejhfenucfkphepudelhedrudefiedrudelrdelgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduleehrddufeeirdduledrleegpdhhvghlohepkhhrvggrtghhvghrrdhlohgtrghlnhgvthdpmhgrihhlfhhrohhmpehrjhifsehrjhifhihsohgtkhhirdhnvghtpdhnsggprhgtphhtthhopedutddprhgtphhtthhopehlihhnuhigqdhpmhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehluhhkrghsiidrlhhusggrsegrrhhmrdgtohhmpdhrtghpthhtohepphgvthgvrhiisehinhhfrhgruggvrggurdhorhhgpdhrtghpthhtohepshhrihhnihhvrghsrdhprghnughruhhvrggurgeslhhinhhugidrihhnthg X-DCC--Metrics: v370.home.net.pl 1024; Body=10 Fuz1=10 Fuz2=10 From: Rafael J. Wysocki Allow em_dev_register_perf_domain() to register a cost-only perf domain with a one-element states table if the :active_power() callback is not provided. Subsequently, this will be used by the intel_pstate driver to register such perf domains for CPUs on hybrid systems. No intentional functional impact. Signed-off-by: Rafael J. Wysocki --- v0.1 -> v0.2: * Do not add one more local variable to em_dev_register_perf_domain() and make it skip the capacity check if the :active_power() callback is NULL. Add a comment explaining why it is correct to do so. For the time being, intel_pstate will only need to be able to say something like "this group of CPUs is preferred to that other group of CPUs for energy-efficiency reasons regardless of the required performance level" (and there may be multiple groups). For this purpose, it only needs a one-element states table in a perf domain for each of the groups and it only needs to set the cost value for each of them to reflect the preference. However, it may need to put CPUs of different capacity into the same group because of favored cores and this doesn't mean that one group will contain CPUs of different mincro-architectures. Favored cores essentially follow the same power-performance curve as the other CPUs of the same type up to a certain point, but they can get beyond that point on the curve which the other CPUs of the same type cannot do. Thus it would make sense to use the same states table for favored cores and the other CPUs of the same type even if there were multiple states in it, and em_pd_get_efficient_state() could easily take that into account by only using the states where "performance" is at most equal to the current CPU capacity. Unfortunately, this doesn't match the em_create_perf_table() code design and in particular em_init_performance() which scales the "performance" values the the current capacity of the "domain leader" CPU represented by "dev". IMV, it should instead scale them to the maximum possible capacity of the highest-capacity CPU in the domain (without requiring equal capacity at all). That would also help to handle the cases when CPU capacity changes, at least on Intel platforms, if it's necessary to worry about this some day. Namely, when CPU capacity is reduced, say by the platform firmware (for thermal or power distribution reasons, for example), this effectively means chopping off the top-most section of the power-performance curve, but the rest of it remains intact, so the same states table as before can be used, only the current CPU capacity needs to be changed to prevent the top-most performance states from being taken into consideration (and analogously when CPU capacity increases). Turbo works pretty much in the same way: When it's enabled, the power-performance curve is effectively extended by adding some states to it and when turbo is disabled, the top-most part of the power-performance curve effectively gets chopped off. This observation may help to avoid having to update the energy model for a chip. --- kernel/power/energy_model.c | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-) Index: linux-pm/kernel/power/energy_model.c =================================================================== --- linux-pm.orig/kernel/power/energy_model.c +++ linux-pm/kernel/power/energy_model.c @@ -426,9 +426,11 @@ static int em_create_pd(struct device *d if (!em_table) goto free_pd; - ret = em_create_perf_table(dev, pd, em_table->state, cb, flags); - if (ret) - goto free_pd_table; + if (cb->active_power) { + ret = em_create_perf_table(dev, pd, em_table->state, cb, flags); + if (ret) + goto free_pd_table; + } ret = em_compute_costs(dev, em_table->state, cb, nr_states, flags); if (ret) @@ -566,6 +568,9 @@ int em_dev_register_perf_domain(struct d if (!dev || !nr_states || !cb) return -EINVAL; + if (!cb->active_power && (!cb->get_cost || nr_states > 1 || microwatts)) + return -EINVAL; + /* * Use a mutex to serialize the registration of performance domains and * let the driver-defined callback functions sleep. @@ -594,7 +599,19 @@ int em_dev_register_perf_domain(struct d * All CPUs of a domain must have the same * micro-architecture since they all share the same * table. + * + * If the :active_power() callback is present, the + * performance values for different states in the table + * computed by em_create_perf_table() depend on the CPU + * capacity which therefore must be the same for all + * CPUs in the domain. However, if the :active_power() + * callback is not NULL, em_create_perf_table() doesn't + * run and there is no requirement regarding CPU + * capacity any more. */ + if (!cb->active_power) + continue; + cap = arch_scale_cpu_capacity(cpu); if (prev_cap && prev_cap != cap) { dev_err(dev, "EM: CPUs of %*pbl must have the same capacity\n", From patchwork Fri Nov 29 16:28:12 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Rafael J. Wysocki" X-Patchwork-Id: 846235 Received: from cloudserver094114.home.pl (cloudserver094114.home.pl [79.96.170.134]) (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 4B8B614600C; Fri, 29 Nov 2024 16:28:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=79.96.170.134 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732897710; cv=none; b=hsVqN6T5QJmJaR4lEtJ9NxiFUN0JLnPUQrI1+RUfIMGG3lFxPqoPPcv720dLUV86zA7dNDi4RjeYxowdzij7OKACcHeCbz6c7XYbxED4Ar0+OhkRLmJ0QoiGXrgbeEpfeT215d432hwGLHLMi0dvL3zPSj7d1W+YIoejLBJlmj8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732897710; c=relaxed/simple; bh=IWjmn1yIhP+LrnlCgE1nt0YBoOITdeu5KNHqPaIxTUs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=HbJtVafEWW88xrRZnBxuN/xfETyff2v+sXw/KYk4ZLlV+2OB7dnk/03iD9WFnwyiPzooPClgG5KDzDSJyDf0y0/3YMeObxKlVIYM04fy5sNnzdKN6RAHILfxQrdV82eS3SlZbGvb7vK5QeOkoK5VrfIPdSdXTBDhnJnb9XReBR0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rjwysocki.net; spf=pass smtp.mailfrom=rjwysocki.net; dkim=pass (2048-bit key) header.d=rjwysocki.net header.i=@rjwysocki.net header.b=SXIhg6v/; arc=none smtp.client-ip=79.96.170.134 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rjwysocki.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rjwysocki.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rjwysocki.net header.i=@rjwysocki.net header.b="SXIhg6v/" Received: from localhost (127.0.0.1) (HELO v370.home.net.pl) by /usr/run/smtp (/usr/run/postfix/private/idea_relay_lmtp) via UNIX with SMTP (IdeaSmtpServer 6.2.1) id bec5d256e9aad60d; Fri, 29 Nov 2024 17:28:19 +0100 Received: from kreacher.localnet (unknown [195.136.19.94]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by cloudserver094114.home.pl (Postfix) with ESMTPSA id CDDE1A47B8B; Fri, 29 Nov 2024 17:28:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rjwysocki.net; s=dkim; t=1732897699; bh=IWjmn1yIhP+LrnlCgE1nt0YBoOITdeu5KNHqPaIxTUs=; h=From:Subject:Date; b=SXIhg6v/vEeNjGzbYz1zWFdGfGW2lEflOMBkI7TfnRd1CRnZhuOfnspfkLa3RDXWj m5wzGQ+l+W7fnvg4i7y/v4DDFT3NzqgIcQlDhcWWOyDWWuQBQuS+HAUoS0oR9yeRyQ ChD1vyMQafRTcCIIvJ3xK2Afg9HQ4TjoBIZH+daLJTytdW1YklogmsKiZ7dmf+lmLj Z/QAxUyxAtwL8SV0AUlDrDwNsFheKHwI3702KD+evPHiU40PrRzSAHqXGifY93nrgr fg+LlyniZf89db84dzBY14Jt/ZO4pExipx3qxes9ssxfaqJvl1I2agkd9smZ1o3g0K uwbBJb4rDC3KA== From: "Rafael J. Wysocki" To: Linux PM Cc: LKML , Lukasz Luba , Peter Zijlstra , Srinivas Pandruvada , Dietmar Eggemann , Morten Rasmussen , Vincent Guittot , Ricardo Neri , Pierre Gondois Subject: [RFC][PATCH v021 9/9] cpufreq: intel_pstate: Add basic EAS support on hybrid platforms Date: Fri, 29 Nov 2024 17:28:12 +0100 Message-ID: <4414387.ejJDZkT8p0@rjwysocki.net> In-Reply-To: <5861970.DvuYhMxLoT@rjwysocki.net> References: <5861970.DvuYhMxLoT@rjwysocki.net> Precedence: bulk X-Mailing-List: linux-pm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-CLIENT-IP: 195.136.19.94 X-CLIENT-HOSTNAME: 195.136.19.94 X-VADE-SPAMSTATE: clean X-VADE-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefuddrheefgdekjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfjqffogffrnfdpggftiffpkfenuceurghilhhouhhtmecuudehtdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkjghfggfgtgesthfuredttddtjeenucfhrhhomhepfdftrghfrggvlhculfdrucghhihsohgtkhhifdcuoehrjhifsehrjhifhihsohgtkhhirdhnvghtqeenucggtffrrghtthgvrhhnpeefudduuedtuefgleffudeigeeitdeufeelvdejgefftdethffhhfethfeljefgteenucffohhmrghinhepkhgvrhhnvghlrdhorhhgnecukfhppeduleehrddufeeirdduledrleegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepudelhedrudefiedrudelrdelgedphhgvlhhopehkrhgvrggthhgvrhdrlhhotggrlhhnvghtpdhmrghilhhfrhhomheprhhjfiesrhhjfiihshhotghkihdrnhgvthdpnhgspghrtghpthhtohepuddtpdhrtghpthhtoheplhhinhhugidqphhmsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqkhgvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhukhgrshiirdhluhgsrgesrghrmhdrtghomhdprhgtphhtthhopehpvghtvghriiesihhnfhhrrgguvggrugdrohhrghdprhgtphhtthhopehsrhhinhhivhgrshdrphg X-DCC--Metrics: v370.home.net.pl 1024; Body=10 Fuz1=10 Fuz2=10 From: Rafael J. Wysocki Modify intel_pstate to register EM perf domains for hybrid domains, introduced previously, via em_dev_register_perf_domain(), and to use em_dev_expand_perf_domain(), also introduced previously, for adding new CPUs to existing EM perf domains when those CPUs become online for the first time after driver initialization. This change is targeting platforms (for example, Lunar Lake) where the "little" CPUs (E-cores) are always more energy-efficient than the "big" or "performance" CPUs (P-cores) when run at the same HWP performance level, so it is sufficient to tell EAS that E-cores are always preferred (so long as there is enough spare capacity on one of them to run the given task). Accordingly, an EM perf domain with 1-element states array is registered for each hybrid domain in the system and each of them is assigned a single cost value. The observation used here is that the IPC ratio between the CPUs in a given hybrid domain is inversely proportional to their performance-to- frequency scaling factor (which must be the same for all of them) and the cost of running on one of them can be assumed to be proportional to that IPC ratio (in principle, the higher the IPC ratio, the more resources are utilized when running at a given frequency, so the cost should be higher). EM perf domains for all CPUs that are online during system startup are registered at the driver initialization time, after asymmetric capacity support has been enabled. For the CPUs that become online later and do not belong to any existing hybrid domain, an EM perf domain is registered when the hybrid domain for the given CPU is created. Signed-off-by: Rafael J. Wysocki --- v0.1 -> v0.2: * Some changes have been dropped because patch [8/9] takes care of what they did now. * Some corner cases related to changing driver operation modes are now handled. For now, I'm sticking to the idea of having one "effective OPP" per EM perf domain because (a) it should be sufficient for the target use case IIUC and (b) anything more complex would need to be tied to the capacity updates carried out by intel_pstate and that would be a much heavier lifting. Besides, I'd generally prefer to avoid updating the energy model on every CPU capacity update because that might need to happen too often. If my understanding of this thread is correct: https://lore.kernel.org/lkml/20240830130309.2141697-1-vincent.guittot@linaro.org/ if there is only one "OPP" per perf domain, within a perf domain EAS will look for a CPU with the highest spare capacity which is exactly what I want and it will generally prefer domains with the lower cost values. So far, I'm not aware of any upcoming hybrid platforms with significant cross-over points between power-performance curves for different types of CPUs, so the current approach (possibly with the addition of some kind of load balancing) should be sufficient for them. If such cross-over points become an issue the future, more complete energy models will need to be used for systems where they are present, but that will require solving the problem with scaling the performance numbers in the states table to the current CPU capacity at init time. --- drivers/cpufreq/intel_pstate.c | 83 +++++++++++++++++++++++++++++++++++++++-- 1 file changed, 79 insertions(+), 4 deletions(-) Index: linux-pm/drivers/cpufreq/intel_pstate.c =================================================================== --- linux-pm.orig/drivers/cpufreq/intel_pstate.c +++ linux-pm/drivers/cpufreq/intel_pstate.c @@ -950,12 +950,67 @@ static DEFINE_MUTEX(hybrid_capacity_lock */ struct hybrid_domain { struct hybrid_domain *next; + struct device *dev; cpumask_t cpumask; int scaling; }; static struct hybrid_domain *hybrid_domains; +static int hybrid_get_cost(struct device *dev, unsigned long freq_not_used, + unsigned long *cost) +{ + struct pstate_data *pd = &all_cpu_data[dev->id]->pstate; + + /* + * The smaller the perf-to-frequency scaling factor, the larger the IPC + * ratio between the CPUs in the given domain and the least capable CPU + * in the system. Assume the cost to be proportional to that IPC ratio + * (and note that perf_ctl_scaling is always the same for all CPUs in + * the system and it is equal to the perf-to-frequency scaling factor + * for one CPU type). + */ + *cost = div_u64(100ULL * pd->perf_ctl_scaling, pd->scaling); + + return 0; +} + +static bool hybrid_register_perf_domain(struct hybrid_domain *hd) +{ + static struct em_data_callback em_cb = EM_ADV_DATA_CB(NULL, hybrid_get_cost); + + /* + * Registering EM perf domains without enabling asymmetric CPU capacity + * support is not really useful and one domain should not be registered + * more than once. + */ + if (!hybrid_max_perf_cpu || hd->dev) + return false; + + hd->dev = get_cpu_device(cpumask_any(&hd->cpumask)); + if (!hd->dev) + return false; + + /* + * Use one EM state in each domain to indicate that the cost associated + * with it applies to all CPUs in it regardless of the frequency. + */ + if (em_dev_register_perf_domain(hd->dev, 1, &em_cb, &hd->cpumask, false)) { + hd->dev = NULL; + return false; + } + + return true; +} + +static void hybrid_register_all_perf_domains(void) +{ + struct hybrid_domain *hd; + + for (hd = hybrid_domains; hd; hd = hd->next) + hybrid_register_perf_domain(hd); +} + static void hybrid_add_to_domain(struct cpudata *cpudata) { int scaling = cpudata->pstate.scaling; @@ -975,6 +1030,8 @@ static void hybrid_add_to_domain(struct return; cpumask_set_cpu(cpu, &hd->cpumask); + if (hd->dev) + em_dev_expand_perf_domain(hd->dev, cpu); pr_debug("CPU %d added to hybrid domain %*pbl\n", cpu, cpumask_pr_args(&hd->cpumask)); @@ -991,11 +1048,14 @@ static void hybrid_add_to_domain(struct hd->scaling = scaling; hd->next = hybrid_domains; hybrid_domains = hd; + if (hybrid_register_perf_domain(hd)) + em_rebuild_perf_domains(); pr_debug("New hybrid domain %*pbl: scaling = %d\n", cpumask_pr_args(&hd->cpumask), hd->scaling); } #else /* CONFIG_ENERGY_MODEL */ +static inline void hybrid_register_all_perf_domains(void) {} static inline void hybrid_add_to_domain(struct cpudata *cpudata) {} #endif /* !CONFIG_ENERGY_MODEL */ @@ -1093,6 +1153,11 @@ static void hybrid_refresh_cpu_capacity_ guard(mutex)(&hybrid_capacity_lock); __hybrid_refresh_cpu_capacity_scaling(); + /* + * Perf domains are not registered before setting hybrid_max_perf_cpu, + * so register them all after setting up CPU capacity scaling. + */ + hybrid_register_all_perf_domains(); } static void hybrid_init_cpu_capacity_scaling(bool refresh) @@ -1116,7 +1181,7 @@ static void hybrid_init_cpu_capacity_sca hybrid_refresh_cpu_capacity_scaling(); /* * Disabling ITMT causes sched domains to be rebuilt to disable asym - * packing and enable asym capacity. + * packing and enable asym capacity and EAS. */ sched_clear_itmt_support(); } @@ -3467,6 +3532,8 @@ static ssize_t intel_pstate_show_status( static int intel_pstate_update_status(const char *buf, size_t size) { + int ret = -EINVAL; + if (size == 3 && !strncmp(buf, "off", size)) { if (!intel_pstate_driver) return -EINVAL; @@ -3476,6 +3543,8 @@ static int intel_pstate_update_status(co cpufreq_unregister_driver(intel_pstate_driver); intel_pstate_driver_cleanup(); + /* Trigger EAS support reconfiguration in case it was used. */ + rebuild_sched_domains_energy(); return 0; } @@ -3487,7 +3556,13 @@ static int intel_pstate_update_status(co cpufreq_unregister_driver(intel_pstate_driver); } - return intel_pstate_register_driver(&intel_pstate); + ret = intel_pstate_register_driver(&intel_pstate); + /* + * If the previous status had been "passive" and the schedutil + * governor had been used, it disabled EAS on exit, so trigger + * sched domains rebuild in case EAS needs to be enabled again. + */ + rebuild_sched_domains_energy(); } if (size == 7 && !strncmp(buf, "passive", size)) { @@ -3499,10 +3574,10 @@ static int intel_pstate_update_status(co intel_pstate_sysfs_hide_hwp_dynamic_boost(); } - return intel_pstate_register_driver(&intel_cpufreq); + ret = intel_pstate_register_driver(&intel_cpufreq); } - return -EINVAL; + return ret; } static int no_load __initdata;