From patchwork Wed Apr 16 18:01:06 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Rafael J. Wysocki" X-Patchwork-Id: 14054410 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 ED03121CFF6; Wed, 16 Apr 2025 18:12:53 +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=1744827175; cv=none; b=Jyl21wUue4vrwPPqOzRgJmjbb7wQEFly8X5LCvOOppPhacuM6gJgEQihFLHpjaS48wt8l1tndMW1gma80+SA3s+Jdz51c2EF5Teq73wPkvKB9y7m5NQqmFelh3pE9j3ekADlX3F70HUSuYWHQhi7UA6dPqRMkyS9wwBWGKSpKvQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744827175; c=relaxed/simple; bh=uaq6qM+Ck6AxQX9+RJSqmkPle2TaQ7kI+Uy3iMaX6a0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=pmEUKyziQF62A0JYi5gtFkyUVkCAnqjLM9a1AT+lPF5DyjWpudaP8ERcStfN7OXFn1IGD0YsLnu4xb0aoxihp4RwrxrOAonh66mD2knnIof3quEKCWYdKOfvaVKmCNrMlPBUH3sUC9U5XZA9OiuIxFi3WxJedyeB9L/Kg9+oGdo= 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=MM3I5nJJ; 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="MM3I5nJJ" 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 7A676662719; Wed, 16 Apr 2025 20:12:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rjwysocki.net; s=dkim; t=1744827171; bh=uaq6qM+Ck6AxQX9+RJSqmkPle2TaQ7kI+Uy3iMaX6a0=; h=From:Subject:Date; b=MM3I5nJJjWyN4SOSGReaZWFXzqWI9ybsdE62U0zfPtnueHY6SNmTgtyOfSFuxSjRm yuw9FSkM/gLQ6JSN7bsNnPIZBqxq+a0q179cFZeepvjQoPsktOHK53zrsZm51Mv5vZ h449YANwSfdVkBWvD7Pa7YrSWZkTJWVjWr9kYb91bvZD+qmRPcUZ2kAYyzy95VHl2d +82xwHaR7+5ne02yHc1hnixQTelZqCxRmanPBiwpeDXrVHWEn7/Ge0KvsH7bOEJvWk 8CbnarFmNN7RBTWMPte/gi8x/BEq2oTegRqwJi/jU0D+hFTnv2239gd3svrjesXgyS L02ABIvmdQVoA== 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 , Christian Loehle Subject: [RFT][PATCH v1 3/8] cpufreq/sched: Allow .setpolicy() cpufreq drivers to enable EAS Date: Wed, 16 Apr 2025 20:01:06 +0200 Message-ID: <8554829.NyiUUSuA9g@rjwysocki.net> In-Reply-To: <3344336.aeNJFYEL58@rjwysocki.net> References: <3344336.aeNJFYEL58@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: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvvdejtdeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecujffqoffgrffnpdggtffipffknecuuegrihhlohhuthemucduhedtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkfgjfhgggfgtsehtufertddttdejnecuhfhrohhmpedftfgrfhgrvghlucflrdcuhgihshhotghkihdfuceorhhjfiesrhhjfiihshhotghkihdrnhgvtheqnecuggftrfgrthhtvghrnhepvdffueeitdfgvddtudegueejtdffteetgeefkeffvdeftddttdeuhfegfedvjefhnecukfhppeduleehrddufeeirdduledrleegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepudelhedrudefiedrudelrdelgedphhgvlhhopehkrhgvrggthhgvrhdrlhhotggrlhhnvghtpdhmrghilhhfrhhomheprhhjfiesrhhjfiihshhotghkihdrnhgvthdpnhgspghrtghpthhtohepuddupdhrtghpthhtoheplhhinhhugidqphhmsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqkhgvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhukhgrshiirdhluhgsrgesrghrmhdrtghomhdprhgtphhtthhopehpvghtvghriiesihhnfhhrrgguvggrugdrohhrghdprhgtphhtthhopehsrhhinhhivhgrshdrphgrnhgurhhuvhgruggrsehlihhnuhigrdh X-DCC--Metrics: v370.home.net.pl 1024; Body=11 Fuz1=11 Fuz2=11 From: Rafael J. Wysocki Some cpufreq drivers, like intel_pstate, have built-in governors that are used instead of regular cpufreq governors, schedutil in particular, but they can work with EAS just fine, so allow EAS to be used with those drivers. Signed-off-by: Rafael J. Wysocki Reviewed-by: Christian Loehle --- v0.3 -> v1 * Rebase on top of the new [1-2/8]. * Update the diagnostic message printed if the conditions are not met. This patch is regarded as a cleanup for 6.16. --- drivers/cpufreq/cpufreq.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -3054,7 +3054,16 @@ guard(cpufreq_policy_read)(policy); - return sugov_is_governor(policy); + /* + * For EAS compatibility, require that either schedutil is the policy + * governor or the policy is governed directly by the cpufreq driver. + * + * In the latter case, it is assumed that EAS can only be enabled by the + * cpufreq driver itself which will not enable EAS if it does not meet + * the EAS' expectations regarding performance scaling response. + */ + return sugov_is_governor(policy) || (!policy->governor && + policy->policy != CPUFREQ_POLICY_UNKNOWN); } bool cpufreq_ready_for_eas(const struct cpumask *cpu_mask) @@ -3064,7 +3073,7 @@ /* Do not attempt EAS if schedutil is not being used. */ for_each_cpu(cpu, cpu_mask) { if (!cpufreq_policy_is_good_for_eas(cpu)) { - pr_debug("rd %*pbl: schedutil is mandatory for EAS\n", + pr_debug("rd %*pbl: EAS requirements not met\n", cpumask_pr_args(cpu_mask)); return false; } From patchwork Wed Apr 16 18:04:23 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Rafael J. Wysocki" X-Patchwork-Id: 14054409 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 BAA2C21CFEA; Wed, 16 Apr 2025 18:12:52 +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=1744827175; cv=none; b=VEMnTICPuZpsdw496eesGR2YBampjUUhDlbNwuBeV59/VybGwK/GCYFLsBqvhbL2GTiVv2j3Mm5EZ+dwqQLr8kkcbrNICL8nHLD2vu6oEP61wiA6iaIs5mcxoTsgoMA4DUczRNhRT0gyNAnOBOmBxx/gENKg0lYkorQQbw48O1M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744827175; c=relaxed/simple; bh=FTOuMPjeTUHaacx8ul/ZKRVujZeYC6eVmnz2zMxqLEM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Eu8EZr+bcKcu9s8zYAZXvFhEwr5VdBOKwcFyLT+qqifLOfVwHgZV8iSXbgDzClTvFLr0mGuKjceLZiGW+nv3edHWvOSxWSs50yj42zAs+P3uMl7/VtyFhl6Sxx7cGPNeEA75wNOiD5+Q/0rRea+r80XtWfhktxXgTR9TXiqN2b8= 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=O08rCwsn; 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="O08rCwsn" 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 988E7662718; Wed, 16 Apr 2025 20:12:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rjwysocki.net; s=dkim; t=1744827170; bh=FTOuMPjeTUHaacx8ul/ZKRVujZeYC6eVmnz2zMxqLEM=; h=From:Subject:Date; b=O08rCwsnw+VV+pxjDr81KbTxjsg9lO8K1MInKwmc1/IadA5zTtJfEQo9BjjvZ1xor nBuTYB0Qtm+YbNfUl8uLGL9Jump3XfN2tgm0xCTkou9CPYBueub5NkwcSVgTWQLfVr LpSREu/xdBtPjPL2/Q2s+C8W4dWEUfHpMPxndUFo2JG9ei1C3tLKVfkENlgF8Y96Ph syUscB/z9AFtMfmJdOyIr2LVGCR2FKGKnzHD0ycj/Q5bsWO4bZ1oDpu+5iR0yz5Yo3 mhxTKFyQNvLViekIRDcJFeiNutxaqZGqtvdMTL7MemPiDMXqeikOCmTwrVVx3ypVtb UcgnhCtFOHOpA== 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 , Christian Loehle Subject: [RFT][PATCH v1 4/8] PM: EM: Move CPU capacity check to em_adjust_new_capacity() Date: Wed, 16 Apr 2025 20:04:23 +0200 Message-ID: <1921260.CQOukoFCf9@rjwysocki.net> In-Reply-To: <3344336.aeNJFYEL58@rjwysocki.net> References: <3344336.aeNJFYEL58@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: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvvdejtdeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecujffqoffgrffnpdggtffipffknecuuegrihhlohhuthemucduhedtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkfgjfhgggfgtsehtufertddttdejnecuhfhrohhmpedftfgrfhgrvghlucflrdcuhgihshhotghkihdfuceorhhjfiesrhhjfiihshhotghkihdrnhgvtheqnecuggftrfgrthhtvghrnhepvdffueeitdfgvddtudegueejtdffteetgeefkeffvdeftddttdeuhfegfedvjefhnecukfhppeduleehrddufeeirdduledrleegnecuvehluhhsthgvrhfuihiivgepudenucfrrghrrghmpehinhgvthepudelhedrudefiedrudelrdelgedphhgvlhhopehkrhgvrggthhgvrhdrlhhotggrlhhnvghtpdhmrghilhhfrhhomheprhhjfiesrhhjfiihshhotghkihdrnhgvthdpnhgspghrtghpthhtohepuddupdhrtghpthhtoheplhhinhhugidqphhmsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqkhgvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhukhgrshiirdhluhgsrgesrghrmhdrtghomhdprhgtphhtthhopehpvghtvghriiesihhnfhhrrgguvggrugdrohhrghdprhgtphhtthhopehsrhhinhhivhgrshdrphgrnhgurhhuvhgruggrsehlihhnuhigrdh X-DCC--Metrics: v370.home.net.pl 1024; Body=11 Fuz1=11 Fuz2=11 From: Rafael J. Wysocki Move the check of the CPU capacity currently stored in the energy model against the arch_scale_cpu_capacity() value to em_adjust_new_capacity() so it will be done regardless of where the latter is called from. This will be useful when a new em_adjust_new_capacity() caller is added subsequently. While at it, move the pd local variable declaration in em_check_capacity_update() into the loop in which it is used. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Reviewed-by: Lukasz Luba --- v0.3 -> v1: * Added R-by from Lukasz. --- kernel/power/energy_model.c | 40 +++++++++++++++++----------------------- 1 file changed, 17 insertions(+), 23 deletions(-) --- a/kernel/power/energy_model.c +++ b/kernel/power/energy_model.c @@ -721,10 +721,24 @@ * Adjustment of CPU performance values after boot, when all CPUs capacites * are correctly calculated. */ -static void em_adjust_new_capacity(struct device *dev, +static void em_adjust_new_capacity(unsigned int cpu, struct device *dev, struct em_perf_domain *pd) { + unsigned long cpu_capacity = arch_scale_cpu_capacity(cpu); struct em_perf_table *em_table; + struct em_perf_state *table; + unsigned long em_max_perf; + + rcu_read_lock(); + table = em_perf_state_from_pd(pd); + em_max_perf = table[pd->nr_perf_states - 1].performance; + rcu_read_unlock(); + + if (em_max_perf == cpu_capacity) + return; + + pr_debug("updating cpu%d cpu_cap=%lu old capacity=%lu\n", cpu, + cpu_capacity, em_max_perf); em_table = em_table_dup(pd); if (!em_table) { @@ -740,9 +754,6 @@ static void em_check_capacity_update(void) { cpumask_var_t cpu_done_mask; - struct em_perf_state *table; - struct em_perf_domain *pd; - unsigned long cpu_capacity; int cpu; if (!zalloc_cpumask_var(&cpu_done_mask, GFP_KERNEL)) { @@ -753,7 +764,7 @@ /* Check if CPUs capacity has changed than update EM */ for_each_possible_cpu(cpu) { struct cpufreq_policy *policy; - unsigned long em_max_perf; + struct em_perf_domain *pd; struct device *dev; if (cpumask_test_cpu(cpu, cpu_done_mask)) @@ -776,24 +787,7 @@ cpumask_or(cpu_done_mask, cpu_done_mask, em_span_cpus(pd)); - cpu_capacity = arch_scale_cpu_capacity(cpu); - - rcu_read_lock(); - table = em_perf_state_from_pd(pd); - em_max_perf = table[pd->nr_perf_states - 1].performance; - rcu_read_unlock(); - - /* - * Check if the CPU capacity has been adjusted during boot - * and trigger the update for new performance values. - */ - if (em_max_perf == cpu_capacity) - continue; - - pr_debug("updating cpu%d cpu_cap=%lu old capacity=%lu\n", - cpu, cpu_capacity, em_max_perf); - - em_adjust_new_capacity(dev, pd); + em_adjust_new_capacity(cpu, dev, pd); } free_cpumask_var(cpu_done_mask); From patchwork Wed Apr 16 18:06:16 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Rafael J. Wysocki" X-Patchwork-Id: 14054408 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 125AC21B1BC; Wed, 16 Apr 2025 18:12:51 +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=1744827174; cv=none; b=d0h4TvGZvxveDbkh0Ef1zfKM2yBDVD5fkYBnkUbP2zyvCEG/X4gt0g8hDKO3rfAS1Ms3qfstTxwOjasSTq2WDw3kcPSDH/mEByVeJXULHsg4tXi4G0Pr7EcRRuOJ00fr2HBq90j8lWi2Y2unlJE4iLkQk7N+Tq79xe6URmrPdAo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744827174; c=relaxed/simple; bh=ORPobRSIjW5dpK/qm7vNZhGebo2cfHQSp0/z/ui7sjc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=HwgYDzLP4JgcjUjV6VAJ27AOfxC27l2/20XBf+Ht3aQf/BcJsxDr2Ac6l9KPHxfdYeRX8PM/tv/bh+dmjFn/5xEMC52SxDRKdqKCsrzMQsXKaJfdXdHShQvSdzpgvX83mJL2Nq3DwOWhwvJGBQeBBaTOt30RsoXNvGtXz5Al/NE= 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=Ne+C/Xkq; 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="Ne+C/Xkq" 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 90CA0662717; Wed, 16 Apr 2025 20:12:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rjwysocki.net; s=dkim; t=1744827169; bh=ORPobRSIjW5dpK/qm7vNZhGebo2cfHQSp0/z/ui7sjc=; h=From:Subject:Date; b=Ne+C/XkqjvJOc0z1k1fivTG0oR7pQsYZruHoBEGjYqG6Bygm+aAZBoptS8pb/AErX 0aZ9pZegKWbvObEPUSilLkJCbBgI1b/glb6S38kBdSqwApDXg9zrxdzcrpOVg4lNAg 6V24dgutuj/9ghdl87fCvO/o9Msv8x/KlwmENIQLmspwyoWJEBXBYEV+EEieO4YMyv bmcAwkUYRfIqaliqqe7JOs6yXed76M58zgdloTLURmzt0v5s7BDeJVe8iv9Tuszzzi /5l7cEbuErVfCY/dglIGsrThxJGP6033gEJG1R2AZnraxZbKd4VVXoMm7BakJdtn3E UDqCEOUIWIghw== 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 , Christian Loehle Subject: [RFT][PATCH v1 5/8] PM: EM: Introduce em_adjust_cpu_capacity() Date: Wed, 16 Apr 2025 20:06:16 +0200 Message-ID: <2649447.Lt9SDvczpP@rjwysocki.net> In-Reply-To: <3344336.aeNJFYEL58@rjwysocki.net> References: <3344336.aeNJFYEL58@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: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvvdejtdeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecujffqoffgrffnpdggtffipffknecuuegrihhlohhuthemucduhedtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkfgjfhgggfgtsehtufertddttdejnecuhfhrohhmpedftfgrfhgrvghlucflrdcuhgihshhotghkihdfuceorhhjfiesrhhjfiihshhotghkihdrnhgvtheqnecuggftrfgrthhtvghrnhepvdffueeitdfgvddtudegueejtdffteetgeefkeffvdeftddttdeuhfegfedvjefhnecukfhppeduleehrddufeeirdduledrleegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepudelhedrudefiedrudelrdelgedphhgvlhhopehkrhgvrggthhgvrhdrlhhotggrlhhnvghtpdhmrghilhhfrhhomheprhhjfiesrhhjfiihshhotghkihdrnhgvthdpnhgspghrtghpthhtohepuddupdhrtghpthhtoheplhhinhhugidqphhmsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqkhgvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhukhgrshiirdhluhgsrgesrghrmhdrtghomhdprhgtphhtthhopehpvghtvghriiesihhnfhhrrgguvggrugdrohhrghdprhgtphhtthhopehsrhhinhhivhgrshdrphgrnhgurhhuvhgruggrsehlihhnuhigrdh X-DCC--Metrics: v370.home.net.pl 1024; Body=11 Fuz1=11 Fuz2=11 From: Rafael J. Wysocki Add a function for updating the Energy Model for a CPU after its capacity has changed, which subsequently will be used by the intel_pstate driver. An EM_PERF_DOMAIN_ARTIFICIAL check is added to em_adjust_new_capacity() to prevent it from calling em_compute_costs() for an "artificial" perf domain with a NULL cb parameter which would cause it to crash. Signed-off-by: Rafael J. Wysocki Reviewed-by: Lukasz Luba --- v0.3 -> v1: * Added R-by from Lukasz. --- include/linux/energy_model.h | 2 ++ kernel/power/energy_model.c | 28 ++++++++++++++++++++++++---- 2 files changed, 26 insertions(+), 4 deletions(-) --- a/include/linux/energy_model.h +++ b/include/linux/energy_model.h @@ -179,6 +179,7 @@ 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_adjust_cpu_capacity(unsigned int cpu); void em_rebuild_sched_domains(void); /** @@ -405,6 +406,7 @@ { return -EINVAL; } +static inline void em_adjust_cpu_capacity(unsigned int cpu) {} static inline void em_rebuild_sched_domains(void) {} #endif --- a/kernel/power/energy_model.c +++ b/kernel/power/energy_model.c @@ -698,10 +698,12 @@ { int ret; - ret = em_compute_costs(dev, em_table->state, NULL, pd->nr_perf_states, - pd->flags); - if (ret) - goto free_em_table; + if (!(pd->flags & EM_PERF_DOMAIN_ARTIFICIAL)) { + ret = em_compute_costs(dev, em_table->state, NULL, + pd->nr_perf_states, pd->flags); + if (ret) + goto free_em_table; + } ret = em_dev_update_perf_domain(dev, em_table); if (ret) @@ -751,6 +753,24 @@ em_recalc_and_update(dev, pd, em_table); } +/** + * em_adjust_cpu_capacity() - Adjust the EM for a CPU after a capacity update. + * @cpu: Target CPU. + * + * Adjust the existing EM for @cpu after a capacity update under the assumption + * that the capacity has been updated in the same way for all of the CPUs in + * the same perf domain. + */ +void em_adjust_cpu_capacity(unsigned int cpu) +{ + struct device *dev = get_cpu_device(cpu); + struct em_perf_domain *pd; + + pd = em_pd_get(dev); + if (pd) + em_adjust_new_capacity(cpu, dev, pd); +} + static void em_check_capacity_update(void) { cpumask_var_t cpu_done_mask; From patchwork Wed Apr 16 18:09:38 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Rafael J. Wysocki" X-Patchwork-Id: 14054407 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 7949D217736; Wed, 16 Apr 2025 18:12:50 +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=1744827172; cv=none; b=n1o360TmuGviNPA7IMfdXB+kFwQORZ7Hk3Dc0EOgEQfoe/NEvB1/je55HGfNpx1X5IYKQAAQa9D86J0WjtJ4BVmc5WTXAEh34Tx5CYvQ4YJnHlSYBGuxbjO2KonsZdlhYE96ZIe0HdzTQi7/YdBJCULjCVIPQjtv9qHak8DSYNQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744827172; c=relaxed/simple; bh=DXUwgGsGvG1/FNFayBBE1LosHw9IhrInavjio6JOKeA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=FMJJBzdPZ4sbPJ6pr/xL1QB71pFv0EWbFp6NPfwjEcCSvIejh/hI3+dIarD3fmwyAVDGHvI3d2Wd3OORzAx1+VewcRVDZIucjwJ8oWFsifcB1IIMHpfxg3HqZGt90hRt8M4MrCOg+Mp4sgz0WyRDKSCUL6eMNOCDduX6qS3dB4c= 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=LPV+bduJ; 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="LPV+bduJ" 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 87078662716; Wed, 16 Apr 2025 20:12:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rjwysocki.net; s=dkim; t=1744827168; bh=DXUwgGsGvG1/FNFayBBE1LosHw9IhrInavjio6JOKeA=; h=From:Subject:Date; b=LPV+bduJXxOuHGIEbiTz+tZwTeoTWAxtp8AxpV5HoSjwIkhL/7DWlisfz62QLMYev e6e6EU/KSeXohwltMr6jAhPG/F3GTVDPWWhtfchcJ5o/3o6kVasSeTX7iKISidTr72 Yw1Cdl9WchOKIrc3NY4+UEwFmnTV4FASUOhAwgphM/cD5r/agytG9/DmVXXVeLTpl0 hyj8r/3KMzI45JidFtzPlfFfy7ASqXWOl1RcAPoyMuYbUzFYQPr7RtaDADwwbB+I60 h7vX2oCkkueh7Ixf9k8vZKnPppRBDN5ZaAfNvKs2w7oog67ydGnaEzHVfdFiOWxzbl DrrXLwcvwVbYw== 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 , Christian Loehle , Tim Chen Subject: [RFT][PATCH v1 6/8] cpufreq: intel_pstate: EAS support for hybrid platforms Date: Wed, 16 Apr 2025 20:09:38 +0200 Message-ID: <3682828.R56niFO833@rjwysocki.net> In-Reply-To: <3344336.aeNJFYEL58@rjwysocki.net> References: <3344336.aeNJFYEL58@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: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvvdejtdehucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecujffqoffgrffnpdggtffipffknecuuegrihhlohhuthemucduhedtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkfgjfhgggfgtsehtufertddttdejnecuhfhrohhmpedftfgrfhgrvghlucflrdcuhgihshhotghkihdfuceorhhjfiesrhhjfiihshhotghkihdrnhgvtheqnecuggftrfgrthhtvghrnhepvdffueeitdfgvddtudegueejtdffteetgeefkeffvdeftddttdeuhfegfedvjefhnecukfhppeduleehrddufeeirdduledrleegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepudelhedrudefiedrudelrdelgedphhgvlhhopehkrhgvrggthhgvrhdrlhhotggrlhhnvghtpdhmrghilhhfrhhomheprhhjfiesrhhjfiihshhotghkihdrnhgvthdpnhgspghrtghpthhtohepuddvpdhrtghpthhtoheplhhinhhugidqphhmsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqkhgvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhukhgrshiirdhluhgsrgesrghrmhdrtghomhdprhgtphhtthhopehpvghtvghriiesihhnfhhrrgguvggrugdrohhrghdprhgtphhtthhopehsrhhinhhivhgrshdrphgrnhgurhhuvhgruggrsehlihhnuhigrdh X-DCC--Metrics: v370.home.net.pl 1024; Body=12 Fuz1=12 Fuz2=12 From: Rafael J. Wysocki Modify intel_pstate to register EM perf domains for CPUs on hybrid platforms and enable EAS on them. 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). However, migrating tasks between CPUs of the same type too often is not desirable because it may hurt both performance and energy efficiency due to leaving warm caches behind. For this reason, register a separate perf domain for each CPU and assign costs for them so that the cost mostly depends on the CPU type, but there is also a small component of it depending on the performance level (utilization) which allows to avoid substantial load imbalances between CPUs of the same type. The observation used here is that the IPC metric value for a given CPU is inversely proportional to its performance-to-frequency scaling factor and the cost of running on it can be assumed to be roughly 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). This main component of the cost is amended with a small addition proportional performance. 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, EM perf domains are registered after setting the asymmetric capacity for them. Signed-off-by: Rafael J. Wysocki --- v0.3 -> v1: * Relocated INTEL_PSTATE_CORE_SCALING define (Tim). * Rephrased a comment regarding EAS disabling (Tim). --- drivers/cpufreq/intel_pstate.c | 131 +++++++++++++++++++++++++++++++++++++++-- 1 file changed, 126 insertions(+), 5 deletions(-) --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -221,6 +221,7 @@ * @sched_flags: Store scheduler flags for possible cross CPU update * @hwp_boost_min: Last HWP boosted min performance * @suspended: Whether or not the driver has been suspended. + * @em_registered: If set, an energy model has been registered. * @hwp_notify_work: workqueue for HWP notifications. * * This structure stores per CPU instance data for all CPUs. @@ -260,6 +261,9 @@ unsigned int sched_flags; u32 hwp_boost_min; bool suspended; +#ifdef CONFIG_ENERGY_MODEL + bool em_registered; +#endif struct delayed_work hwp_notify_work; }; @@ -303,6 +307,7 @@ static struct cpufreq_driver *intel_pstate_driver __read_mostly; +#define INTEL_PSTATE_CORE_SCALING 100000 #define HYBRID_SCALING_FACTOR_ADL 78741 #define HYBRID_SCALING_FACTOR_MTL 80000 #define HYBRID_SCALING_FACTOR_LNL 86957 @@ -311,7 +316,7 @@ static inline int core_get_scaling(void) { - return 100000; + return INTEL_PSTATE_CORE_SCALING; } #ifdef CONFIG_ACPI @@ -945,12 +950,105 @@ */ static DEFINE_MUTEX(hybrid_capacity_lock); +#ifdef CONFIG_ENERGY_MODEL +#define HYBRID_EM_STATE_COUNT 4 + +static int hybrid_active_power(struct device *dev, unsigned long *power, + unsigned long *freq) +{ + /* + * Create "utilization bins" of 0-40%, 40%-60%, 60%-80%, and 80%-100% + * of the maximum capacity such that two CPUs of the same type will be + * regarded as equally attractive if the utilization of each of them + * falls into the same bin, which should prevent tasks from being + * migrated between them too often. + * + * For this purpose, return the "frequency" of 2 for the first + * performance level and otherwise leave the value set by the caller. + */ + if (!*freq) + *freq = 2; + + /* No power information. */ + *power = EM_MAX_POWER; + + return 0; +} + +static int hybrid_get_cost(struct device *dev, unsigned long freq, + unsigned long *cost) +{ + struct pstate_data *pstate = &all_cpu_data[dev->id]->pstate; + + /* + * The smaller the perf-to-frequency scaling factor, the larger the IPC + * ratio between the given CPU and the least capable CPU in the system. + * Regard that IPC ratio as the primary cost component and assume that + * the scaling factors for different CPU types will differ by at least + * 5% and they will not be above INTEL_PSTATE_CORE_SCALING. + * + * Add the freq value to the cost, so that the cost of running on CPUs + * of the same type in different "utilization bins" is different. + */ + *cost = div_u64(100ULL * INTEL_PSTATE_CORE_SCALING, pstate->scaling) + freq; + + return 0; +} + +static bool hybrid_register_perf_domain(unsigned int cpu) +{ + static const struct em_data_callback cb + = EM_ADV_DATA_CB(hybrid_active_power, hybrid_get_cost); + struct cpudata *cpudata = all_cpu_data[cpu]; + struct device *cpu_dev; + + /* + * 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 || cpudata->em_registered) + return false; + + cpu_dev = get_cpu_device(cpu); + if (!cpu_dev) + return false; + + if (em_dev_register_perf_domain(cpu_dev, HYBRID_EM_STATE_COUNT, &cb, + cpumask_of(cpu), false)) + return false; + + cpudata->em_registered = true; + + return true; +} + +static void hybrid_register_all_perf_domains(void) +{ + unsigned int cpu; + + for_each_online_cpu(cpu) + hybrid_register_perf_domain(cpu); +} + +static void hybrid_update_perf_domain(struct cpudata *cpu) +{ + if (cpu->em_registered) + em_adjust_cpu_capacity(cpu->cpu); +} +#else /* !CONFIG_ENERGY_MODEL */ +static inline bool hybrid_register_perf_domain(unsigned int cpu) { return false; } +static inline void hybrid_register_all_perf_domains(void) {} +static inline void hybrid_update_perf_domain(struct cpudata *cpu) {} +#endif /* CONFIG_ENERGY_MODEL */ + static void hybrid_set_cpu_capacity(struct cpudata *cpu) { arch_set_cpu_capacity(cpu->cpu, cpu->capacity_perf, hybrid_max_perf_cpu->capacity_perf, cpu->capacity_perf, cpu->pstate.max_pstate_physical); + hybrid_update_perf_domain(cpu); pr_debug("CPU%d: perf = %u, max. perf = %u, base perf = %d\n", cpu->cpu, cpu->capacity_perf, hybrid_max_perf_cpu->capacity_perf, @@ -1039,6 +1137,11 @@ 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) @@ -1066,7 +1169,7 @@ 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(); } @@ -1144,6 +1247,14 @@ } hybrid_set_cpu_capacity(cpu); + /* + * If the CPU was offline to start with and it is going online for the + * first time, a perf domain needs to be registered for it if hybrid + * capacity scaling has been enabled already. In that case, sched + * domains need to be rebuilt to take the new perf domain into account. + */ + if (hybrid_register_perf_domain(cpu->cpu)) + em_rebuild_sched_domains(); unlock: mutex_unlock(&hybrid_capacity_lock); @@ -3397,6 +3508,8 @@ 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; @@ -3406,6 +3519,8 @@ cpufreq_unregister_driver(intel_pstate_driver); intel_pstate_driver_cleanup(); + /* Disable EAS support in case it was used. */ + rebuild_sched_domains_energy(); return 0; } @@ -3417,7 +3532,13 @@ 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)) { @@ -3429,10 +3550,10 @@ 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; From patchwork Wed Apr 16 18:10:50 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Rafael J. Wysocki" X-Patchwork-Id: 14054406 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 2A18D215F43; Wed, 16 Apr 2025 18:12:48 +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=1744827171; cv=none; b=Oy/xx/TOx9MPrqY0czZZMwcBrtsTYm8B73jTtbDtxNUAMoVYQ+Lyh23prh1Xv5qLO12CPIypnQBlPWS+AwDv9x+biHAUsKd8EbAxDNo7SkSfD5x/9c7m48L+2Pyb6ytRM3513uPDP13ncYnADW6yaX7eB8rv4QNhUWCXZ2YJ0/8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744827171; c=relaxed/simple; bh=E23xdNKoe2mDxY9sAKw+UB4JLbdwV3PEW8QZm66WUAc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=rDSDSj2dSOyX/pUE2e25BMmg5zwbvDZS/wBJ9Nk2n7Zc3HnQBNuouvqf346pBq+lczkUP+2kFkj8TTL5I7VwJqFDb9diMGgXUa9wQD7t8SZfIRU3/mtQDVYqfZbQKIxppWDmFG8OZE+vo0EZHENm/HLfeZ92gZQ0Xjhq/dhwhJA= 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=M/SXTHBB; 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="M/SXTHBB" 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 9C6AF662715; Wed, 16 Apr 2025 20:12:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rjwysocki.net; s=dkim; t=1744827167; bh=E23xdNKoe2mDxY9sAKw+UB4JLbdwV3PEW8QZm66WUAc=; h=From:Subject:Date; b=M/SXTHBBggDgj1khm+745Tm48eqxgEyxltDSOgxmFMr17CHkH2OcGx9JTX3MPQWbf CsDmVwHpsszAUdHEZJ2RC3j+54+MpM+Cl9Lxzw/falybNIAp+/fZgCuLkI0Es29YWw Z17uRKXZE7D52cMuvq1kEca6f0d+Zzjst8V05xSl783B6/9As0u10qWr+C6AiR1zhs vJbV5u9RoQiquu4gqG3Rqe61493SNWS3pZX8m6cmY4KojihkmgDXIlz+y6ipWV2u3o nAohMYgcLa+LxI2hDJQPN+J4V960edIH5Ai3zdmdyU1kiCSgf1PvqC90TuoKD6CxjM jq7IMUuugFkEQ== 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 , Christian Loehle , Tim Chen Subject: [RFT][PATCH v1 7/8] cpufreq: intel_pstate: Align perf domains with L2 cache Date: Wed, 16 Apr 2025 20:10:50 +0200 Message-ID: <1964444.taCxCBeP46@rjwysocki.net> In-Reply-To: <3344336.aeNJFYEL58@rjwysocki.net> References: <3344336.aeNJFYEL58@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: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvvdejtdeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecujffqoffgrffnpdggtffipffknecuuegrihhlohhuthemucduhedtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkfgjfhgggfgtsehtufertddttdejnecuhfhrohhmpedftfgrfhgrvghlucflrdcuhgihshhotghkihdfuceorhhjfiesrhhjfiihshhotghkihdrnhgvtheqnecuggftrfgrthhtvghrnhepvdffueeitdfgvddtudegueejtdffteetgeefkeffvdeftddttdeuhfegfedvjefhnecukfhppeduleehrddufeeirdduledrleegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepudelhedrudefiedrudelrdelgedphhgvlhhopehkrhgvrggthhgvrhdrlhhotggrlhhnvghtpdhmrghilhhfrhhomheprhhjfiesrhhjfiihshhotghkihdrnhgvthdpnhgspghrtghpthhtohepuddvpdhrtghpthhtoheplhhinhhugidqphhmsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqkhgvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhukhgrshiirdhluhgsrgesrghrmhdrtghomhdprhgtphhtthhopehpvghtvghriiesihhnfhhrrgguvggrugdrohhrghdprhgtphhtthhopehsrhhinhhivhgrshdrphgrnhgurhhuvhgruggrsehlihhnuhigrdh X-DCC--Metrics: v370.home.net.pl 1024; Body=12 Fuz1=12 Fuz2=12 From: Rafael J. Wysocki On some hybrid platforms a group of cores (referred to as a module) may share an L2 cache in which case they also share a voltage regulator and always run at the same frequency (while not in idle states). For this reason, make hybrid_register_perf_domain() in the intel_pstate driver add all CPUs sharing an L2 cache to the same perf domain for EAS. Signed-off-by: Rafael J. Wysocki Signed-off-by: Christian Loehle --- New in v1. --- drivers/cpufreq/intel_pstate.c | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -999,8 +999,11 @@ { static const struct em_data_callback cb = EM_ADV_DATA_CB(hybrid_active_power, hybrid_get_cost); + struct cpu_cacheinfo *cacheinfo = get_cpu_cacheinfo(cpu); + const struct cpumask *cpumask = cpumask_of(cpu); struct cpudata *cpudata = all_cpu_data[cpu]; struct device *cpu_dev; + int ret; /* * Registering EM perf domains without enabling asymmetric CPU capacity @@ -1014,9 +1017,25 @@ if (!cpu_dev) return false; - if (em_dev_register_perf_domain(cpu_dev, HYBRID_EM_STATE_COUNT, &cb, - cpumask_of(cpu), false)) + if (cacheinfo) { + unsigned int i; + + /* Find the L2 cache and the CPUs sharing it. */ + for (i = 0; i < cacheinfo->num_leaves; i++) { + if (cacheinfo->info_list[i].level == 2) { + cpumask = &cacheinfo->info_list[i].shared_cpu_map; + break; + } + } + } + + ret = em_dev_register_perf_domain(cpu_dev, HYBRID_EM_STATE_COUNT, &cb, + cpumask, false); + if (ret) { + cpudata->em_registered = ret == -EEXIST; + return false; + } cpudata->em_registered = true; From patchwork Wed Apr 16 18:12:07 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Rafael J. Wysocki" X-Patchwork-Id: 14054405 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 1AB221AF0BC; Wed, 16 Apr 2025 18:12:47 +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=1744827170; cv=none; b=fCWGbPsHjl/zBNTOcn/6231SuJ87bvb3gG/WuprNvxoMXmHXXLfqhWuwFfjNQMNCLnIQVlk++0XuR1jzJ64JoVWiAxaZnjdNCKm88nH6UsPworbakr1veksrDwU9M1GRD+7kN7jX4jve8KXxRrjPCDDDcmg20zlETBIk77dLm2g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744827170; c=relaxed/simple; bh=p6lZpJkVX9UkBcwJa0YIg46R9uDoxvpxGH9F8PLq/Q8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=D/vTBd6/m7GdsrHa2yNJJHpkUVpoypZC3iz2X91ql2ty3xYSU2bQCT03G5m4bN4Nm2WAaP55hlwiq3LnChUcfNxlfZI6la0mKkMtHS3ZW99MQInPLGtpC9if/pMHOB/dMIzJXe1h0OLqhHW7R2Ot6ludX4sgO94ZbWxZBhTL3Ok= 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=I6igity2; 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="I6igity2" 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 4D75B662714; Wed, 16 Apr 2025 20:12:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rjwysocki.net; s=dkim; t=1744827165; bh=p6lZpJkVX9UkBcwJa0YIg46R9uDoxvpxGH9F8PLq/Q8=; h=From:Subject:Date; b=I6igity2Dw9lBf3q+iF7XjByV2oQ+CxjerVombDSs9e3eZlfgzmgYrE9ioA1tDt32 AYa2vfEWV+3ualUWbVnc58vkEfP9P1G1rtQCIfN6i5yQqhWPLgkIFeW8ZQ/FvJpAKU f5R37AnG108I2I7jW2mp5BAFQQIWxeyIoTCSd+SOdn/8+nbj9WfR02wy0a8nzMivig Kx6ORQMbyzlBEWnGch3sg/KseHdEuea3Tro3LRfBQnATd5EKKCMHBxOfHvpkEJhUAk V/q1uAgMUzY2yUXQeGd/ISQZXXmsJxHWskQrpKEEc1gGW/uQbD0s9ZUKcmFqQO0nqN JoxHsggIi7C9Q== 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 , Christian Loehle Subject: [RFT][PATCH v1 8/8] cpufreq: intel_pstate: EAS: Increase cost for CPUs using L3 cache Date: Wed, 16 Apr 2025 20:12:07 +0200 Message-ID: <47159248.fMDQidcC6G@rjwysocki.net> In-Reply-To: <3344336.aeNJFYEL58@rjwysocki.net> References: <3344336.aeNJFYEL58@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: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvvdejtdehucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecujffqoffgrffnpdggtffipffknecuuegrihhlohhuthemucduhedtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkfgjfhgggfgtsehtufertddttdejnecuhfhrohhmpedftfgrfhgrvghlucflrdcuhgihshhotghkihdfuceorhhjfiesrhhjfiihshhotghkihdrnhgvtheqnecuggftrfgrthhtvghrnhepvdffueeitdfgvddtudegueejtdffteetgeefkeffvdeftddttdeuhfegfedvjefhnecukfhppeduleehrddufeeirdduledrleegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepudelhedrudefiedrudelrdelgedphhgvlhhopehkrhgvrggthhgvrhdrlhhotggrlhhnvghtpdhmrghilhhfrhhomheprhhjfiesrhhjfiihshhotghkihdrnhgvthdpnhgspghrtghpthhtohepuddupdhrtghpthhtoheplhhinhhugidqphhmsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqkhgvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhukhgrshiirdhluhgsrgesrghrmhdrtghomhdprhgtphhtthhopehpvghtvghriiesihhnfhhrrgguvggrugdrohhrghdprhgtphhtthhopehsrhhinhhivhgrshdrphgrnhgurhhuvhgruggrsehlihhnuhigrdh X-DCC--Metrics: v370.home.net.pl 1024; Body=11 Fuz1=11 Fuz2=11 From: Rafael J. Wysocki On some hybrid platforms some efficient CPUs (E-cores) are not connected to the L3 cache, but there are no other differences between them and the other E-cores that use L3. In that case, it is generally more efficient to run "light" workloads on the E-cores that do not use L3 and allow all of the cores using L3, including P-cores, to go into idle states. For this reason, slightly increase the cost for all CPUs sharing the L3 cache to make EAS prefer CPUs that do not use it to the other CPUs with the same perf-to-frequency scaling factor (if any). Signed-off-by: Rafael J. Wysocki --- drivers/cpufreq/intel_pstate.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -979,6 +979,7 @@ unsigned long *cost) { struct pstate_data *pstate = &all_cpu_data[dev->id]->pstate; + struct cpu_cacheinfo *cacheinfo = get_cpu_cacheinfo(dev->id); /* * The smaller the perf-to-frequency scaling factor, the larger the IPC @@ -991,6 +992,13 @@ * of the same type in different "utilization bins" is different. */ *cost = div_u64(100ULL * INTEL_PSTATE_CORE_SCALING, pstate->scaling) + freq; + /* + * Inrease the cost slightly for CPUs able to access L3 to avoid litting + * it up too eagerly in case some other CPUs of the same type cannot + * access it. + */ + if (cacheinfo->num_levels >= 3) + (*cost)++; return 0; }