cpufreq Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Renninger <trenn@suse.de>
To: cpufreq <cpufreq@www.linux.org.uk>
Cc: Dave Jones <davej@redhat.com>
Subject: [PATCH] Correct symlink cpufreq handling when offlining dual/ht core machines
Date: Mon, 27 Nov 2006 16:06:15 +0100	[thread overview]
Message-ID: <1164639976.4656.188.camel@queen.suse.de> (raw)

[-- Attachment #1: Type: text/plain, Size: 2317 bytes --]

The bug does not break anything currently (AFAIK), the fix is just for
correctness...

Here an example:
l -d cpu*/cpufreq
cpu0/cpufreq/
cpu1/cpufreq -> ../../../../devices/system/cpu/cpu0/cpufreq/
cpu2/cpufreq/
cpu3/cpufreq -> ../../../../devices/system/cpu/cpu2/cpufreq/

echo 0 >cpu2/online
cpu0/cpufreq/
cpu1/cpufreq -> ../../../../devices/system/cpu/cpu0/cpufreq/
cpu3/cpufreq/

Without the patch the last dir (cpu3/cpufreq/, which previously was a
symlink) would be missing now.

echo 1 >cpu2/online

l -d cpu*/cpufreq
cpu0/cpufreq/
cpu1/cpufreq -> ../../../../devices/system/cpu/cpu0/cpufreq/
cpu2/cpufreq -> ../../../../devices/system/cpu/cpu3/cpufreq/
cpu3/cpufreq/

Difference after offlining/onlining one "main" core with this patch:
The CPU which has a symlink cpufreq and the CPU which has the origin dir
have will be exchanged if the core without the symlink got
offlined/onlined.

Patch is against 2.6.18 with my previous one ("If a CPU gets onlined set
the governor to the one that is run on other CPUs") also applied,
therefore it might fuz a bit...

Please consider to apply to 2.6.20-rc1




Correct symlink cpufreq handling when offlining dual/ht core machines

If you offline a main CPU, the symlink of the cpufreq dir of the managed
CPU just vanished. Now it get's it's own cpufreq managing directory. As soon
as the sibling core is onlined again, this one gets a symlinked cpufreq dir.

Signed-off-by: Thomas Renninger <trenn@suse.de>

---
 drivers/cpufreq/cpufreq.c |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

Index: linux-2.6.18_cpufreq_symlink_problem/drivers/cpufreq/cpufreq.c
===================================================================
--- linux-2.6.18_cpufreq_symlink_problem.orig/drivers/cpufreq/cpufreq.c
+++ linux-2.6.18_cpufreq_symlink_problem/drivers/cpufreq/cpufreq.c
@@ -817,7 +817,7 @@ static int cpufreq_remove_dev (struct sy
 	unsigned long flags;
 	struct cpufreq_policy *data;
 #ifdef CONFIG_SMP
-	struct sys_device *cpu_sys_dev;
+	struct sys_device *cpu_sys_dev = NULL;
 	unsigned int j;
 #endif
 
@@ -910,6 +910,12 @@ static int cpufreq_remove_dev (struct sy
 	kfree(data);
 
 	cpufreq_debug_enable_ratelimit();
+
+	if (cpu_sys_dev){
+		dprintk("Registering managed CPU as managing CPU");
+		cpufreq_add_dev(cpu_sys_dev);
+	}
+
 	return 0;
 }
 


[-- Attachment #2: cpufreq_recover_symlinks.patch --]
[-- Type: text/x-patch, Size: 1206 bytes --]

Correct symlink cpufreq handling when offlining dual/ht core machines

If you offline a main CPU, the symlink of the cpufreq dir of the managed
CPU just vanished. Now it get's it's own cpufreq managing directory, as soon
as the sibling core is onlined again, this one gets a symlinked cpufreq dir.

Signed-off-by: Thomas Renninger <trenn@suse.de>

---
 drivers/cpufreq/cpufreq.c |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

Index: linux-2.6.18_cpufreq_symlink_problem/drivers/cpufreq/cpufreq.c
===================================================================
--- linux-2.6.18_cpufreq_symlink_problem.orig/drivers/cpufreq/cpufreq.c
+++ linux-2.6.18_cpufreq_symlink_problem/drivers/cpufreq/cpufreq.c
@@ -817,7 +817,7 @@ static int cpufreq_remove_dev (struct sy
 	unsigned long flags;
 	struct cpufreq_policy *data;
 #ifdef CONFIG_SMP
-	struct sys_device *cpu_sys_dev;
+	struct sys_device *cpu_sys_dev = NULL;
 	unsigned int j;
 #endif
 
@@ -910,6 +910,12 @@ static int cpufreq_remove_dev (struct sy
 	kfree(data);
 
 	cpufreq_debug_enable_ratelimit();
+
+	if (cpu_sys_dev){
+		dprintk("Registering managed CPU as managing CPU");
+		cpufreq_add_dev(cpu_sys_dev);
+	}
+
 	return 0;
 }
 

[-- Attachment #3: Type: text/plain, Size: 147 bytes --]

_______________________________________________
Cpufreq mailing list
Cpufreq@lists.linux.org.uk
http://lists.linux.org.uk/mailman/listinfo/cpufreq

                 reply	other threads:[~2006-11-27 15:06 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=1164639976.4656.188.camel@queen.suse.de \
    --to=trenn@suse.de \
    --cc=cpufreq@www.linux.org.uk \
    --cc=davej@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox