passive cooling policy

Hi,

I have some general issues about passive cooling in userspace. Please correct me if I am wrong at some point:

1) Cooling policy (active, passive) should be adjusted through the cooling mode interface. At most every tenth brand-new laptop supports cooling mode interface.

2) Cooling policy could be simulated by overriding active/passive trip points (fans shouldn't be touched but are controlled by kernel). BIOS must export active/passive trip point values to effectively lower fan activity.

3) If passive limit is reached, kernel throttles cpu and tries to set cpufreq to lowest step. Only way to find out whether machine is passively cooled is in polling /proc/acpi/thermal_zone/*/state. (Is it right that cpufreq daemons poll this file to be informed of kernel forced cpufreq slow downs?)

If above is right, I have some enhancement suggestions:

1) inform userspace that cpu speed is increased/decreased through a thermal event.
-> avoid userspace progs polling /proc/acpi/thermal_zone/*/state to be informed whether the system is slowed down.

2) Allow setting a passive trip point even BIOS does not export a passive trip point value and initialise tc1, tc2 and tsp with some sensible default values.
-> you could lower fan activity on every laptop/workstation that supports throttling/cpufreq regardless whether the BIOS exports any passive trip points/cooling mode (event most laptop vendors don't care about trip points).

If it is possible that this goes mainline, then I'll try to provide a patch (as this should be quite easy to implement, I think).

Thanks for response,

Thomas

-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Hi Thomas,

Why do cpufreq daemons want to know that? And the ordering is important:
first scale CPU frequency be means of cpufreq, _then_ throttle the CPU.

Again, I do not see a reason for why this needs to be exported to userspace.

As long as this allows an additional, probably lower "trip point" for _passive_ cooling, this sounds like a good idea. It cannot hurt as long as it doesn't disable the BIOS-initialized active cooling.

Dominik

-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Hi Dominik,

Maybe I miss some easy solution to work around this problem, but currently I have the problem that:

E.g. machine enters passive cooling mode, cpu usage is high, cpufreq daemon sets machine to highest cpufreq step, but it is ignored. Processor cools down, cpu usage is still high, cpufreq is still in lowered step, because the daemon thinks it already set the frequency to highest step.

I did a short test some time ago and I thought that kernel does not remember userspace cpufreq settings while in passive mode. I currently see three solutions for this:

Checking whether the cpufreq setting really took place.
Polling whether machine is in passive cooling mode.
Last and for my opinion most proper one is by just send a thermal event when entering/leaving passive cooling mode. I saw that some kind of hysteresis algorithm is implemented, so the event should not be thrown too often.

My main concern is stated above, but it could also be convenient for informing the user or monitoring programs.

I currently have not much time, but I try to have a look at this soon.

Thomas

-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

What about this patch? Untested, uncompiled, just that you get the picture. As all changes in passive cooling utilizing cpufreq result in a cpufreq_update_policy() call, and that calls the governor with CPUFREQ_GOV_LIMITS, the userspace-desired frequency is restored. A good side-effect is that resume doesn't need to be special-cased any longer.

@@ -68,7 +68,8 @@
  */
 static unsigned int	cpu_max_freq[NR_CPUS];
 static unsigned int	cpu_min_freq[NR_CPUS];
-static unsigned int	cpu_cur_freq[NR_CPUS];
+static unsigned int	cpu_cur_freq[NR_CPUS]; /* current CPU freq */
+static unsigned int	cpu_set_freq[NR_CPUS]; /* CPU freq desired by userspace */
 static unsigned int	cpu_is_managed[NR_CPUS];
 static struct cpufreq_policy current_policy[NR_CPUS];
 

@@ -82,13 +83,6 @@
 {
         struct cpufreq_freqs *freq = data;
 
-	/* Don't update cur_freq if CPU is managed and we're
-	 * waking up: else we won't remember what frequency 
-	 * we need to set the CPU to.
-	 */
-	if (cpu_is_managed[freq->cpu] && (val == CPUFREQ_RESUMECHANGE))
-		return 0;
-
 	cpu_cur_freq[freq->cpu] = freq->new;
 
         return 0;

@@ -119,6 +113,8 @@
 	if (freq > cpu_max_freq[cpu])
 		freq = cpu_max_freq[cpu];
 
+	cpufreq_set_freq[cpu] = freq;
+
 	/*
 	 * We're safe from concurrent calls to ->target() here
 	 * as we hold the userspace_sem lock. If we were calling

@@ -523,6 +519,7 @@
 		cpu_min_freq[cpu] = policy->min;
 		cpu_max_freq[cpu] = policy->max;
 		cpu_cur_freq[cpu] = policy->cur;
+		cpu_set_freq[cpu] = policy->cur;
 		sysfs_create_file (&policy->kobj, &freq_attr_scaling_setspeed.attr);
 		memcpy (&current_policy[cpu], policy, sizeof(struct cpufreq_policy));
 		up(&userspace_sem);

@@ -532,6 +529,7 @@
 		cpu_is_managed[cpu] = 0;
 		cpu_min_freq[cpu] = 0;
 		cpu_max_freq[cpu] = 0;
+		cpu_set_freq[cpu] = 0;
 		sysfs_remove_file (&policy->kobj, &freq_attr_scaling_setspeed.attr);
 		up(&userspace_sem);
 		break;

@@ -539,15 +537,18 @@
 		down(&userspace_sem);
 		cpu_min_freq[cpu] = policy->min;
 		cpu_max_freq[cpu] = policy->max;
-		if (policy->max < cpu_cur_freq[cpu])
+		if (policy->max < cpu_cur_freq[cpu]) {
+			cpu_set_freq[cpu] = policy->max;
 			__cpufreq_driver_target(&current_policy[cpu], policy->max, 
 			      CPUFREQ_RELATION_H);
-		else if (policy->min > cpu_cur_freq[cpu])
+		} else if (policy->min > cpu_cur_freq[cpu]) {
+			cpu_set_freq[cpu] = policy->min;
 			__cpufreq_driver_target(&current_policy[cpu], policy->min, 
 			      CPUFREQ_RELATION_L);
-		else
-			__cpufreq_driver_target(&current_policy[cpu], cpu_cur_freq[cpu],
+		} else {
+			__cpufreq_driver_target(&current_policy[cpu], cpu_set_freq[cpu],
 			      CPUFREQ_RELATION_L);
+		}
 		memcpy (&current_policy[cpu], policy, sizeof(struct cpufreq_policy));
 		up(&userspace_sem);
 		break;

for the other reasons: OK.

Dominik

-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php