cpufreq Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] cpufreq: Expose cpufreq coordination requirements regardless of coordination mechanism
@ 2008-03-21  0:43 Darrick J. Wong
  2008-03-21 22:41 ` Andrew Morton
  0 siblings, 1 reply; 3+ messages in thread
From: Darrick J. Wong @ 2008-03-21  0:43 UTC (permalink / raw)
  To: cpufreq; +Cc: linux-kernel, Pallipadi, Venkatesh

Currently, affected_cpus shows which CPUs need to have their frequency
coordinated in software.  When hardware coordination is in use, the
contents of this file appear the same as when no coordination is
required.  This can lead to some confusion among user-space programs,
for example, that do not know that extra coordination is required to
force a CPU core to a particular speed to control power consumption.

To fix this, create a "related_cpus" attribute that always displays
the coordination map regardless of whatever coordination strategy
the cpufreq driver uses (sw or hw).  If the cpufreq driver does not
provide a value, fall back to policy->cpus.

Signed-off-by: Darrick J. Wong <djwong@us.ibm.com>
---

 arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c |    1 +
 drivers/cpufreq/cpufreq.c                  |   29 +++++++++++++++++++++++-----
 include/linux/cpufreq.h                    |    3 ++-
 3 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c b/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
index a962dcb..2e21d35 100644
--- a/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
+++ b/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
@@ -591,6 +591,7 @@ static int acpi_cpufreq_cpu_init(struct cpufreq_policy *policy)
 	    policy->shared_type == CPUFREQ_SHARED_TYPE_ANY) {
 		policy->cpus = perf->shared_cpu_map;
 	}
+	policy->related_cpus = perf->shared_cpu_map;
 
 #ifdef CONFIG_SMP
 	dmi_check_system(sw_any_bug_dmi_table);
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 35a26a3..38bf03f 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -582,15 +582,13 @@ out:
 	i += sprintf(&buf[i], "\n");
 	return i;
 }
-/**
- * show_affected_cpus - show the CPUs affected by each transition
- */
-static ssize_t show_affected_cpus (struct cpufreq_policy * policy, char *buf)
+
+static ssize_t show_cpus(cpumask_t mask, char *buf)
 {
 	ssize_t i = 0;
 	unsigned int cpu;
 
-	for_each_cpu_mask(cpu, policy->cpus) {
+	for_each_cpu_mask(cpu, mask) {
 		if (i)
 			i += scnprintf(&buf[i], (PAGE_SIZE - i - 2), " ");
 		i += scnprintf(&buf[i], (PAGE_SIZE - i - 2), "%u", cpu);
@@ -601,6 +599,25 @@ static ssize_t show_affected_cpus (struct cpufreq_policy * policy, char *buf)
 	return i;
 }
 
+/**
+ * show_related_cpus - show the CPUs affected by each transition even if
+ * hw coordination is in use
+ */
+static ssize_t show_related_cpus(struct cpufreq_policy *policy, char *buf)
+{
+	if (cpus_empty(policy->related_cpus))
+		return show_cpus(policy->cpus, buf);
+	return show_cpus(policy->related_cpus, buf);
+}
+
+/**
+ * show_affected_cpus - show the CPUs affected by each transition
+ */
+static ssize_t show_affected_cpus(struct cpufreq_policy *policy, char *buf)
+{
+	return show_cpus(policy->cpus, buf);
+}
+
 static ssize_t store_scaling_setspeed(struct cpufreq_policy *policy,
 		const char *buf, size_t count)
 {
@@ -645,6 +662,7 @@ define_one_ro(cpuinfo_max_freq);
 define_one_ro(scaling_available_governors);
 define_one_ro(scaling_driver);
 define_one_ro(scaling_cur_freq);
+define_one_ro(related_cpus);
 define_one_ro(affected_cpus);
 define_one_rw(scaling_min_freq);
 define_one_rw(scaling_max_freq);
@@ -657,6 +675,7 @@ static struct attribute * default_attrs[] = {
 	&scaling_min_freq.attr,
 	&scaling_max_freq.attr,
 	&affected_cpus.attr,
+	&related_cpus.attr,
 	&scaling_governor.attr,
 	&scaling_driver.attr,
 	&scaling_available_governors.attr,
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index ddd8652..a881fd6 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -83,7 +83,8 @@ struct cpufreq_real_policy {
 };
 
 struct cpufreq_policy {
-	cpumask_t		cpus;	/* affected CPUs */
+	cpumask_t		cpus;	/* CPUs requiring sw coordination */
+	cpumask_t		related_cpus; /* CPUs with any coordination */
 	unsigned int		shared_type; /* ANY or ALL affected CPUs
 						should set cpufreq */
 	unsigned int		cpu;    /* cpu nr of registered CPU */

^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] cpufreq: Expose cpufreq coordination requirements regardless of coordination mechanism
  2008-03-21  0:43 [PATCH] cpufreq: Expose cpufreq coordination requirements regardless of coordination mechanism Darrick J. Wong
@ 2008-03-21 22:41 ` Andrew Morton
  2008-03-21 23:56   ` [PATCH] cpufreq: Document the currently undocumented parts of the sysfs interface Darrick J. Wong
  0 siblings, 1 reply; 3+ messages in thread
From: Andrew Morton @ 2008-03-21 22:41 UTC (permalink / raw)
  To: Darrick J. Wong; +Cc: cpufreq, linux-kernel, venkatesh.pallipadi

On Thu, 20 Mar 2008 17:43:54 -0700
"Darrick J. Wong" <djwong@us.ibm.com> wrote:

> Currently, affected_cpus shows which CPUs need to have their frequency
> coordinated in software.  When hardware coordination is in use, the
> contents of this file appear the same as when no coordination is
> required.  This can lead to some confusion among user-space programs,
> for example, that do not know that extra coordination is required to
> force a CPU core to a particular speed to control power consumption.
> 
> To fix this, create a "related_cpus" attribute that always displays
> the coordination map regardless of whatever coordination strategy
> the cpufreq driver uses (sw or hw).  If the cpufreq driver does not
> provide a value, fall back to policy->cpus.

I was going to ding you for not updating the kernel->userspace API
documentation.  But it seems that none of this interface is documented
anyway :(

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [PATCH] cpufreq: Document the currently undocumented parts of the sysfs interface
  2008-03-21 22:41 ` Andrew Morton
@ 2008-03-21 23:56   ` Darrick J. Wong
  0 siblings, 0 replies; 3+ messages in thread
From: Darrick J. Wong @ 2008-03-21 23:56 UTC (permalink / raw)
  To: Andrew Morton; +Cc: cpufreq, linux-kernel, venkatesh.pallipadi

On Fri, Mar 21, 2008 at 03:41:24PM -0700, Andrew Morton wrote:

> I was going to ding you for not updating the kernel->userspace API
> documentation.  But it seems that none of this interface is documented
> anyway :(

Actually, I deserve the ding, for there _is_ a description of some of
the sysfs files.  However, there are some that are not mentioned in the
documentation, so add them to the user's guide.

Signed-off-by: Darrick J. Wong <djwong@us.ibm.com>
---

 Documentation/cpu-freq/user-guide.txt |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/Documentation/cpu-freq/user-guide.txt b/Documentation/cpu-freq/user-guide.txt
index af3b925..6c442d8 100644
--- a/Documentation/cpu-freq/user-guide.txt
+++ b/Documentation/cpu-freq/user-guide.txt
@@ -154,6 +154,11 @@ scaling_governor,		and by "echoing" the name of another
 				that some governors won't load - they only
 				work on some specific architectures or
 				processors.
+
+cpuinfo_cur_freq :		Current speed of the CPU, in KHz.
+
+scaling_available_frequencies : List of available frequencies, in KHz.
+
 scaling_min_freq and
 scaling_max_freq		show the current "policy limits" (in
 				kHz). By echoing new values into these
@@ -162,6 +167,15 @@ scaling_max_freq		show the current "policy limits" (in
 				first set scaling_max_freq, then
 				scaling_min_freq.
 
+affected_cpus :			List of CPUs that require software coordination
+				of frequency.
+
+related_cpus :			List of CPUs that need some sort of frequency
+				coordination, whether software or hardware.
+
+scaling_driver :		Hardware driver for cpufreq.
+
+scaling_cur_freq :		Current frequency of the CPU, in KHz.
 
 If you have selected the "userspace" governor which allows you to
 set the CPU operating frequency to a specific value, you can read out

^ permalink raw reply related	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2008-03-21 23:56 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-03-21  0:43 [PATCH] cpufreq: Expose cpufreq coordination requirements regardless of coordination mechanism Darrick J. Wong
2008-03-21 22:41 ` Andrew Morton
2008-03-21 23:56   ` [PATCH] cpufreq: Document the currently undocumented parts of the sysfs interface Darrick J. Wong

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox