public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	x86 Maintainers <x86@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Linux PM <linux-pm@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Ricardo Neri <ricardo.neri@intel.com>,
	Tim Chen <tim.c.chen@intel.com>
Subject: Re: [RFC][PATCH v1 3/3] cpufreq: intel_pstate: Set asymmetric CPU capacity on hybrid systems
Date: Fri, 24 May 2024 14:43:41 +0200	[thread overview]
Message-ID: <91b37d34-6d9a-4623-87d8-0ff648ea2415@arm.com> (raw)
In-Reply-To: <1799046.VLH7GnMWUR@kreacher>

On 25/04/2024 21:06, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> Make intel_pstate use the HWP_HIGHEST_PERF values from
> MSR_HWP_CAPABILITIES to set asymmetric CPU capacity information
> via the previously introduced arch_set_cpu_capacity() on hybrid
> systems without SMT.
> 
> Setting asymmetric CPU capacity is generally necessary to allow the
> scheduler to compute task sizes in a consistent way across all CPUs
> in a system where they differ by capacity.  That, in turn, should help
> to improve task placement and load balancing decisions.  It is also
> necessary for the schedutil cpufreq governor to operate as expected
> on hybrid systems where tasks migrate between CPUs of different
> capacities.

[...]

For Arm64 we expose the cpu_capacity under:

  /sys/devices/system/cpu/cpu*/cpu_capacity

Might be handy for X86 hybrid as well.

Code snippet copied from from drivers/base/arch_topology.c :

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 9e94b3f05a57..c445e5d1efc8 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -3746,5 +3746,49 @@ static int __init intel_pstate_setup(char *str)
 }
 early_param("intel_pstate", intel_pstate_setup);
 
+static ssize_t cpu_capacity_show(struct device *dev,
+                                 struct device_attribute *attr,
+                                 char *buf)
+{
+       struct cpu *cpu = container_of(dev, struct cpu, dev);
+
+       return sysfs_emit(buf, "%lu\n", arch_scale_cpu_capacity(cpu->dev.id));
+}
+
+static DEVICE_ATTR_RO(cpu_capacity);
+
+static int cpu_capacity_sysctl_add(unsigned int cpu)
+{
+       struct device *cpu_dev = get_cpu_device(cpu);
+
+       if (!cpu_dev)
+               return -ENOENT;
+
+       device_create_file(cpu_dev, &dev_attr_cpu_capacity);
+
+       return 0;
+}
+
+static int cpu_capacity_sysctl_remove(unsigned int cpu)
+{
+       struct device *cpu_dev = get_cpu_device(cpu);
+
+       if (!cpu_dev)
+               return -ENOENT;
+
+       device_remove_file(cpu_dev, &dev_attr_cpu_capacity);
+
+       return 0;
+}
+
+static int register_cpu_capacity_sysctl(void)
+{
+       cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "topology/cpu-capacity",
+                         cpu_capacity_sysctl_add, cpu_capacity_sysctl_remove);
+
+       return 0;
+}
+subsys_initcall(register_cpu_capacity_sysctl);
+

[...]

      parent reply	other threads:[~2024-05-24 12:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-25 19:03 [RFC][PATCH v1 0/3] x86 / intel_pstate: Set asymmetric CPU capacity on hybrid systems Rafael J. Wysocki
2024-04-25 19:04 ` [RFC][PATCH v1 1/3] x86/sched: Introduce arch_rebuild_sched_domains() Rafael J. Wysocki
2024-04-25 19:04 ` [RFC][PATCH v1 2/3] " Rafael J. Wysocki
2024-04-25 19:14   ` Rafael J. Wysocki
2024-04-25 19:15     ` [RFC][PATCH v1 2/3] x86/sched: Add basic support for CPU capacity scaling Rafael J. Wysocki
2024-04-25 19:06 ` [RFC][PATCH v1 3/3] cpufreq: intel_pstate: Set asymmetric CPU capacity on hybrid systems Rafael J. Wysocki
2024-05-02 10:42   ` Dietmar Eggemann
2024-05-03  3:32     ` Ricardo Neri
2024-05-03 18:29       ` Dietmar Eggemann
2024-05-06 14:39     ` Rafael J. Wysocki
2024-05-21 12:51       ` Dietmar Eggemann
2024-05-24 12:43   ` Dietmar Eggemann [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=91b37d34-6d9a-4623-87d8-0ff648ea2415@arm.com \
    --to=dietmar.eggemann@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=ricardo.neri@intel.com \
    --cc=rjw@rjwysocki.net \
    --cc=srinivas.pandruvada@linux.intel.com \
    --cc=tglx@linutronix.de \
    --cc=tim.c.chen@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox