All of lore.kernel.org
 help / color / mirror / Atom feed
From: Beata Michalska <beata.michalska@arm.com>
To: Prashant Malani <pmalani@google.com>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Jie Zhan <zhanjie9@hisilicon.com>,
	Ionela Voinescu <ionela.voinescu@arm.com>,
	Ben Segall <bsegall@google.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	open list <linux-kernel@vger.kernel.org>,
	"open list:CPU FREQUENCY SCALING FRAMEWORK"
	<linux-pm@vger.kernel.org>, Mel Gorman <mgorman@suse.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Valentin Schneider <vschneid@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	z00813676 <zhenglifeng1@huawei.com>,
	sudeep.holla@arm.com
Subject: Re: [PATCH v2 2/2] cpufreq: CPPC: Dont read counters for idle CPUs
Date: Wed, 6 Aug 2025 09:21:36 +0200	[thread overview]
Message-ID: <aJMCgGt5zu5Dhrd5@arm.com> (raw)
In-Reply-To: <CAFivqmKgiVEWMQ90Lh6T+Y44E6m4jmdF5sUFfVNTmgVHOMtZsw@mail.gmail.com>

On Mon, Aug 04, 2025 at 01:55:37PM -0700, Prashant Malani wrote:
> On Fri, 1 Aug 2025 at 02:16, Prashant Malani <pmalani@google.com> wrote:
> > On Thu, 31 Jul 2025 at 13:31, Beata Michalska <beata.michalska@arm.com> wrote:
> > > Thank you for the info, but I'm exploring ways that will not increase the time
> > > window between the reads.
> >
> > IMO this issue is intractable on non-RT OSes like Linux (at least,
> > Linux when it is not compiled for RT), since we basically need to
> > ensure atomicity for the reading of both ref and del registers together.
> > We can't disable preemption here, since some of
> > the code paths (like PCC regs) acquire semaphores [2].
> 
> Actually, minor correction here. The PCC path is not the issue.
> It's the ffh read path[3], which requires interrupts to be enabled.
> Larger point still stands.
> 
> [3] https://elixir.bootlin.com/linux/v6.16-rc7/source/arch/arm64/kernel/topology.c#L451
> 
> BR,
> 
> -Prashant

Would you mind giving it a go and see whether that improves things on your end ?
Note that this is a quick and semi-dirty hack though.

---
BR
Beata

diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 5d07ee85bdae..65adb78a9a87 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -479,6 +479,11 @@ bool cpc_ffh_supported(void)
 	return true;
 }
 
+bool cpc_burst_read_supported(void)
+{
+	return cpc_ffh_supported();
+}
+
 int cpc_read_ffh(int cpu, struct cpc_reg *reg, u64 *val)
 {
 	int ret = -EOPNOTSUPP;
@@ -501,6 +506,61 @@ int cpc_read_ffh(int cpu, struct cpc_reg *reg, u64 *val)
 	return ret;
 }
 
+
+struct cpc_burst_read {
+	struct cpc_reg_sample *samples;
+	size_t  count;
+};
+
+void counters_burst_read_on_cpu(void *arg)
+{
+	struct cpc_burst_read *desc = arg;
+	u64 value;
+	int i;
+
+	for (i = 0; i < desc->count; ++i) {
+		switch ((u64)desc->samples[i].reg->address) {
+		case 0x0:
+			value = read_corecnt();
+			break;
+		case 0x1:
+			value = read_constcnt();
+			break;
+		}
+		*(u64 *)desc->samples[i].sample_value = value;
+	}
+
+	for (i = 0; i < desc->count; ++i) {
+		struct cpc_reg *reg = desc->samples[i].reg;
+
+		value = *(u64 *)desc->samples[i].sample_value;
+		value &= GENMASK_ULL(reg->bit_offset + reg->bit_width - 1,
+				     reg->bit_offset);
+		value >>= reg->bit_offset;
+		*(u64 *)desc->samples[i].sample_value = value;
+	}
+}
+
+static inline bool cpc_reg_supported(struct cpc_reg *reg)
+{
+	return !((u64)reg->address != 0x0 || (u64)reg->address != 0x1);
+}
+
+int cpc_burst_read_ffh(int cpu, struct cpc_reg_sample *samples, size_t count)
+{
+	struct cpc_burst_read desc = { samples, count };
+	int ret = -EOPNOTSUPP;
+	int i;
+
+	for (i = 0; i < count; ++i) {
+		if (!cpc_reg_supported(samples[i].reg))
+			return ret;
+	}
+
+	smp_call_function_single(cpu, counters_burst_read_on_cpu, &desc, 1);
+	return 0;
+}
+
 int cpc_write_ffh(int cpunum, struct cpc_reg *reg, u64 val)
 {
 	return -EOPNOTSUPP;
diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
index 6b649031808f..c070627e4a1e 100644
--- a/drivers/acpi/cppc_acpi.c
+++ b/drivers/acpi/cppc_acpi.c
@@ -617,6 +617,11 @@ bool __weak cpc_supported_by_cpu(void)
 	return false;
 }
 
+bool __weak cpc_burst_read_supported(void)
+{
+	return false;
+}
+
 /**
  * pcc_data_alloc() - Allocate the pcc_data memory for pcc subspace
  * @pcc_ss_id: PCC Subspace index as in the PCC client ACPI package.
@@ -1077,6 +1082,21 @@ static int cpc_read(int cpu, struct cpc_register_resource *reg_res, u64 *val)
 	return 0;
 }
 
+static int cpc_burst_read(int cpu, struct cpc_reg_sample *samples, size_t count)
+{
+	int i;
+
+	// Just for now - only ffh
+	if (!cpc_ffh_supported())
+		return -EINVAL;
+
+	for (i = 0; i < count; ++i)
+		if (samples[i].reg->space_id != ACPI_ADR_SPACE_FIXED_HARDWARE)
+			return -EINVAL;
+	return cpc_burst_read_ffh(cpu, samples, count);
+}
+
+
 static int cpc_write(int cpu, struct cpc_register_resource *reg_res, u64 val)
 {
 	int ret_val = 0;
@@ -1515,8 +1535,21 @@ int cppc_get_perf_ctrs(int cpunum, struct cppc_perf_fb_ctrs *perf_fb_ctrs)
 		}
 	}
 
-	cpc_read(cpunum, delivered_reg, &delivered);
-	cpc_read(cpunum, reference_reg, &reference);
+	// Verify whether the registers can be requested in one go
+	if (delivered_reg->type != ACPI_TYPE_INTEGER &&
+	    reference_reg->type != ACPI_TYPE_INTEGER &&
+	    cpc_burst_read_supported()) {
+
+		struct cpc_reg_sample samples[] = {
+			{ &delivered_reg->cpc_entry.reg, &delivered },
+			{ &reference_reg->cpc_entry.reg, &reference }
+		};
+
+		cpc_burst_read(cpunum, samples, ARRAY_SIZE(samples));
+	} else {
+		cpc_read(cpunum, delivered_reg, &delivered);
+		cpc_read(cpunum, reference_reg, &reference);
+	}
 	cpc_read(cpunum, ref_perf_reg, &ref_perf);
 
 	/*
diff --git a/include/acpi/cppc_acpi.h b/include/acpi/cppc_acpi.h
index 325e9543e08f..f094e275834a 100644
--- a/include/acpi/cppc_acpi.h
+++ b/include/acpi/cppc_acpi.h
@@ -52,6 +52,12 @@ struct cpc_reg {
 	u64 address;
 } __packed;
 
+
+struct cpc_reg_sample {
+	struct cpc_reg *reg;
+	void *sample_value;
+};
+
 /*
  * Each entry in the CPC table is either
  * of type ACPI_TYPE_BUFFER or
@@ -165,6 +171,7 @@ extern unsigned int cppc_get_transition_latency(int cpu);
 extern bool cpc_ffh_supported(void);
 extern bool cpc_supported_by_cpu(void);
 extern int cpc_read_ffh(int cpunum, struct cpc_reg *reg, u64 *val);
+extern int cpc_burst_read_ffh(int cpunum, struct cpc_reg_sample *samples, size_t count);
 extern int cpc_write_ffh(int cpunum, struct cpc_reg *reg, u64 val);
 extern int cppc_get_epp_perf(int cpunum, u64 *epp_perf);
 extern int cppc_set_epp_perf(int cpu, struct cppc_perf_ctrls *perf_ctrls, bool enable);
@@ -229,6 +236,10 @@ static inline int cpc_read_ffh(int cpunum, struct cpc_reg *reg, u64 *val)
 {
 	return -EOPNOTSUPP;
 }
+static inline int cpc_burst_read_ffh(int cpunum, struct cpc_reg_sample *samples, size_t count)
+{
+	return -EOPNOTSUPP;
+}
 static inline int cpc_write_ffh(int cpunum, struct cpc_reg *reg, u64 val)
 {
 	return -EOPNOTSUPP;
-- 


  reply	other threads:[~2025-08-06  7:22 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-19  0:09 [PATCH v2 0/2] cpufreq: CPPC: idle cpu perf handling Prashant Malani
2025-06-19  0:09 ` [PATCH v2 1/2] sched: Expose idle_cpu() to modules Prashant Malani
2025-06-19  0:09 ` [PATCH v2 2/2] cpufreq: CPPC: Dont read counters for idle CPUs Prashant Malani
2025-06-20  3:53   ` Jie Zhan
2025-06-20  5:07     ` Prashant Malani
2025-06-26 18:42       ` Prashant Malani
2025-06-27  7:54       ` Jie Zhan
2025-06-27 17:07         ` Prashant Malani
2025-07-02 18:38           ` Prashant Malani
2025-07-03  9:29             ` Beata Michalska
2025-07-07  8:32             ` Beata Michalska
2025-07-09 17:25               ` Prashant Malani
2025-07-09 22:49                 ` Prashant Malani
2025-07-14  9:30                   ` Beata Michalska
2025-07-15  6:28                     ` Prashant Malani
2025-07-21 17:00                       ` Rafael J. Wysocki
2025-07-21 19:40                         ` Prashant Malani
2025-07-22  3:27                           ` Viresh Kumar
2025-07-22  6:02                             ` Prashant Malani
2025-07-30  7:31                               ` Prashant Malani
2025-07-31  8:27                                 ` Beata Michalska
2025-07-31 11:13                                   ` Viresh Kumar
2025-07-31 20:23                                     ` Beata Michalska
2025-08-01  4:43                                       ` Viresh Kumar
2025-08-07  0:19                                         ` Prashant Malani
2025-08-11  6:05                                           ` Viresh Kumar
2025-08-11 18:43                                             ` Prashant Malani
2025-08-11 19:19                                               ` Rafael J. Wysocki
2025-08-11 20:01                                                 ` Prashant Malani
2025-08-14 11:48                                                   ` Rafael J. Wysocki
2025-08-15  5:12                                                     ` Prashant Malani
2025-08-16  8:25                                                       ` Prashant Malani
2025-08-13 10:12                                               ` Beata Michalska
2025-07-31 16:51                                   ` Prashant Malani
2025-07-31 20:30                                     ` Beata Michalska
2025-08-01  9:16                                       ` Prashant Malani
2025-08-04 20:55                                         ` Prashant Malani
2025-08-06  7:21                                           ` Beata Michalska [this message]
2025-08-07  0:01                                             ` Prashant Malani
2025-08-07 10:24                                               ` Beata Michalska
2025-08-08  2:14                                                 ` Prashant Malani
2025-08-13 10:15                                                   ` Beata Michalska
2025-08-13 22:25                                                     ` Prashant Malani
2025-07-07  8:35         ` Beata Michalska

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=aJMCgGt5zu5Dhrd5@arm.com \
    --to=beata.michalska@arm.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=ionela.voinescu@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=pmalani@google.com \
    --cc=rafael@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=sudeep.holla@arm.com \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@linaro.org \
    --cc=vschneid@redhat.com \
    --cc=zhanjie9@hisilicon.com \
    --cc=zhenglifeng1@huawei.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.