[PATCH] support for CPUFREQ_ETERNAL drivers by the ondemand governor

[PATCH] support for CPUFREQ_ETERNAL drivers by the ondemand governor

[Eric Piel]

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

Hello,

For now the ondemand governor doesn't support the drivers which reports 
a transition latency of CPUFREQ_ETERNAL. That's really a problem because 
most of the drivers declare such a latency (simply because it's not 
known, not really because the transition will take an eternal time). 
All userspace daemons suport those drivers, they just don't pay 
attention to the transition latency.

This patch proposes to consider a CPUFREQ_ETERNAL latency as the maximum 
possible latency of the governor (10 ms). I think this should be 
conservative enough to be safe with any driver.

Hoping you like it,
Eric

--
Support for CPUFREQ_ETERNAL drivers by the ondemand governor.

Signed-off-by: Eric Piel <eric.piel@tremplin-utc.net>
--

[-- Attachment #2: ondemand-accept-eternel-transition-latency-2.6.11-rc3.patch --]
[-- Type: text/x-patch, Size: 1345 bytes --]

--- linux-2.6.11-rc3/drivers/cpufreq/cpufreq_ondemand.c.orig	2005-02-05 17:09:30.000000000 +0100
+++ linux-2.6.11-rc3/drivers/cpufreq/cpufreq_ondemand.c	2005-02-05 18:02:55.000000000 +0100
@@ -56,7 +56,7 @@ static unsigned int 				def_sampling_rat
 #define MAX_SAMPLING_RATE			(500 * def_sampling_rate)
 #define DEF_SAMPLING_RATE_LATENCY_MULTIPLIER	(1000)
 #define DEF_SAMPLING_DOWN_FACTOR		(10)
-#define TRANSITION_LATENCY_LIMIT		(10 * 1000)
+#define TRANSITION_LATENCY_LIMIT		(10 * 1000 * 1000) /* ns */
 #define sampling_rate_in_HZ(x)			(((x * HZ) < (1000 * 1000))?1:((x * HZ) / (1000 * 1000)))
 
 static void do_dbs_timer(void *data);
@@ -385,8 +385,8 @@ static int cpufreq_governor_dbs(struct c
 		    (!policy->cur))
 			return -EINVAL;
 
-		if (policy->cpuinfo.transition_latency >
-				(TRANSITION_LATENCY_LIMIT * 1000))
+		if ((policy->cpuinfo.transition_latency > TRANSITION_LATENCY_LIMIT) &&
+		    (policy->cpuinfo.transition_latency != CPUFREQ_ETERNAL))
 			return -EINVAL;
 		if (this_dbs_info->enable) /* Already enabled */
 			break;
@@ -416,6 +416,8 @@ static int cpufreq_governor_dbs(struct c
 			/* policy latency is in nS. Convert it to uS first */
 
 			latency = policy->cpuinfo.transition_latency;
+			if (latency == CPUFREQ_ETERNAL)
+				latency = TRANSITION_LATENCY_LIMIT;
 			if (latency < 1000)
 				latency = 1000;
 

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

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

Re: [PATCH] support for CPUFREQ_ETERNAL drivers by the ondemand governor

[Dominik Brodowski]

On Sun, Feb 06, 2005 at 11:33:49PM +0100, Eric Piel wrote:
> Hello,
> 
> For now the ondemand governor doesn't support the drivers which reports 
> a transition latency of CPUFREQ_ETERNAL. That's really a problem because 
> most of the drivers declare such a latency (simply because it's not 
> known, not really because the transition will take an eternal time). 
> All userspace daemons suport those drivers, they just don't pay 
> attention to the transition latency.
> 
> This patch proposes to consider a CPUFREQ_ETERNAL latency as the maximum 
> possible latency of the governor (10 ms). I think this should be 
> conservative enough to be safe with any driver.

No. CPUFREQ_ETERNAL is there to assert no dynamic frequency governor runs
with this driver. If a driver is safe to run on dynamic frequency governors
like ondemand, fix the latency value instead.

	Dominik

[PATCH] transition latency of speedstep-ich

[Eric Piel]

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

Dominik Brodowski a écrit :
> On Sun, Feb 06, 2005 at 11:33:49PM +0100, Eric Piel wrote:
:
>>This patch proposes to consider a CPUFREQ_ETERNAL latency as the maximum 
>>possible latency of the governor (10 ms). I think this should be 
>>conservative enough to be safe with any driver.
>  
> No. CPUFREQ_ETERNAL is there to assert no dynamic frequency governor runs
> with this driver. If a driver is safe to run on dynamic frequency governors
> like ondemand, fix the latency value instead.
> 
OK, so here is a patch for vanilla 2.6.11 to set the transition latency 
of speedstep-ich (the only driver which I can test in addtion to 
p4-clockmod). Actually it was quite hard to find, the intel manual 
(29834006.pdf) doesn't assert this latency clearly. From what I 
understood the frequency transition could take up to about 40µs (p.44) 
while the voltage transition could take up to 100µs (p.22 and p.58). So 
I put 100µs as the transition latency of this driver.

I've tried it on my computer, it works, and the ondemand governor can 
now support my hardware!

Hope you like it,
Eric

--
Set the transition latency of speedstep-ich to 100µs as described in 
intel's manual.

Signed-off-by: Eric Piel <eric.piel@tremplin-utc.net>
--

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: speedstep-ich-transition-latency-2.6.11.patch --]
[-- Type: text/x-patch; name="speedstep-ich-transition-latency-2.6.11.patch", Size: 581 bytes --]

--- linux-2.6.11/arch/i386/kernel/cpu/cpufreq/speedstep-ich.c.orig	2005-02-07 23:52:55.000000000 +0100
+++ linux-2.6.11/arch/i386/kernel/cpu/cpufreq/speedstep-ich.c	2005-03-06 17:51:04.000000000 +0100
@@ -335,7 +335,8 @@
 
 	/* cpuinfo and default policy values */
 	policy->governor = CPUFREQ_DEFAULT_GOVERNOR;
-	policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
+ 	/* Max 100µs, according to intel's 29834006.pdf p.22 */
+	policy->cpuinfo.transition_latency = 100000;
 	policy->cur = speed;
 
 	result = cpufreq_frequency_table_cpuinfo(policy, speedstep_freqs);

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

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

Re: [PATCH] transition latency of speedstep-ich (third try)

[Eric Piel]

19.09.2005 12:18, Dominik Brodowski wrote/a écrit:
> Hi,
> 
> On Sun, Sep 18, 2005 at 11:15:09PM +0200, Eric Piel wrote:
> 
>>Here is my third try to get speedstep-ich compatible with the ondemand 
>>governor. Taking into account the comments of Dominik I've gone through 
>>the intel documentation in order to get the transition latency depending 
>>on the processor.
> 
> Thanks for doing so!
> 
> 
>>+	case SPEEDSTEP_PROCESSOR_PIII_T:
>>+		/* Max 100??s, according to intel's 29834006.pdf p.22 */
> 
> 			  ^^
> The greek sign in microsecond can't be printed well, so I suggest you use
> "us" instead.
> 
> 
>>+		 * Max ~42??s -> 50??s, according to intel's 25068607.pdf p.40 and p.50
> 
> 			  ^^       ^^
> same here.
Ok, sorry, just forgot it was not an ASCII character (even xterm 
supports UTF-8 nowadays ;-) ). I'll resend as soon as I get the answer 
from Venki.

> Other than that, it'd be great if you, Venki, could take a look at the
> technical side of this. Because of the cpufreq list still being down, I
> attached the message in full below.
Indeed, Venki, I would be extremely thanksfull if you could validate 
those numbers. To sum up, could you confirm that the transition latency 
between two frequencies never exeeds:
* 100us for Coppermine and Tualatin
* 50us for Pentium 4 M

Cheers
Eric



> 
>>While for the centrino processors such information is clearly written, 
>>this was not the case for the processors managed by speedstep-ich. I did 
>>my best to understand the electrical timing descriptions and the results 
>>look realistic, but I can't guaranty 100% certainty. At least, the code 
>>hasn't destroyed my pentium coppermine yet ;-)
>>
>>It's against 2.6.13, hope you like it...
>>
>>Eric
>>
>>--
>>Set the transition latency of speedstep-ich depending on the processor, 
>>using information taken from intel's manuals.
>>
>>Signed-off-by: Eric Piel <eric.piel@tremplin-utc.net>
>>--
> 
> 
>>--- linux-2.6.13/arch/i386/kernel/cpu/cpufreq/speedstep-ich.c.bak	2005-08-08 10:14:35.000000000 +0200
>>+++ linux-2.6.13/arch/i386/kernel/cpu/cpufreq/speedstep-ich.c	2005-09-17 12:50:27.000000000 +0200
>>@@ -301,6 +301,35 @@ static int speedstep_verify (struct cpuf
>> }
>> 
>> 
>>+/**
>>+ * speedstep_get_transition_latency - returns the maximum transition latency
>>+ * of the current processor
>>+ * @processor: type of processor
>>+ *
>>+ * The CPU transition latency depends on the type of CPU, so we get it
>>+ * from a database.
>>+ */
>>+static unsigned int speedstep_get_transition_latency(unsigned int processor)
>>+{
>>+	switch (processor) {
>>+	case SPEEDSTEP_PROCESSOR_PIII_C:
>>+	case SPEEDSTEP_PROCESSOR_PIII_C_EARLY:
>>+		/* According to intel's p3_ds.pdf p.23 and table 22, similar to PIII_T */
>>+	case SPEEDSTEP_PROCESSOR_PIII_T:
>>+		/* Max 100??s, according to intel's 29834006.pdf p.22 */
>>+		return 100000;
>>+	case SPEEDSTEP_PROCESSOR_P4M:
>>+		/* 
>>+		 * Depends on the bus clock, which should be at least 100MHz.
>>+		 * Max ~42??s -> 50??s, according to intel's 25068607.pdf p.40 and p.50
>>+		 */
>>+		return 50000;
>>+	default:
>>+		/* No info has yet be found, so we are conservative */
>>+		return CPUFREQ_ETERNAL;
>>+	}
>>+}
>>+
>> static int speedstep_cpu_init(struct cpufreq_policy *policy)
>> {
>> 	int result = 0;
>>@@ -335,7 +364,8 @@ static int speedstep_cpu_init(struct cpu
>> 
>> 	/* cpuinfo and default policy values */
>> 	policy->governor = CPUFREQ_DEFAULT_GOVERNOR;
>>-	policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
>>+	policy->cpuinfo.transition_latency = 
>>+		speedstep_get_transition_latency(speedstep_processor);
>> 	policy->cur = speed;
>> 
>> 	result = cpufreq_frequency_table_cpuinfo(policy, speedstep_freqs);

RE: [PATCH] support for CPUFREQ_ETERNAL drivers by the ondemand governor

[Pallipadi, Venkatesh]

Hi,

The ondemand governor uses the transitions latency information 
to set a proper default sampling rate. 
For example, if the transitions latency is 100uS, the default 
sampling rate used by ondemand governor is 100 mS. So, wrong 
assumption about the transition latency can lead to frequent 
sampling and overhead in the kernel. Transition Latency doesn't 
matter a lot for userspace governors as their sampling rate is 
typically much less (few seconds).

I agree that changing CPUFREQ_ETERNAL to 10mS would be safe with 
most of the governors and this change would enable such governors 
to work with ondemand. But, making this assumption inside 
the ondemand governor makes me little nervous. What if some 
particular driver has latency more than 10mS (there may not be 
any such driver today. But, some new driver can come up in future). 

I feel better way to workarond this issue is to have one more 
intermediate #define, say CPUFREQ_LATENCY_LESS_THAN_1MS defined 
to 1MS and use it in place of CPUFREQ_ETERNAL in all the drivers 
that know their transition latency is less than this value and  
don't know their exact transition latency.

Thanks,
Venki

>-----Original Message-----
>From: Eric Piel [mailto:Eric.Piel@tremplin-utc.net] 
>Sent: Sunday, February 06, 2005 2:34 PM
>To: Pallipadi, Venkatesh; Nakajima, Jun
>Cc: cpufreq@ZenII.linux.org.uk
>Subject: [PATCH] support for CPUFREQ_ETERNAL drivers by the 
>ondemand governor
>
>Hello,
>
>For now the ondemand governor doesn't support the drivers 
>which reports 
>a transition latency of CPUFREQ_ETERNAL. That's really a 
>problem because 
>most of the drivers declare such a latency (simply because it's not 
>known, not really because the transition will take an eternal time). 
>All userspace daemons suport those drivers, they just don't pay 
>attention to the transition latency.
>
>This patch proposes to consider a CPUFREQ_ETERNAL latency as 
>the maximum 
>possible latency of the governor (10 ms). I think this should be 
>conservative enough to be safe with any driver.
>
>Hoping you like it,
>Eric
>
>--
>Support for CPUFREQ_ETERNAL drivers by the ondemand governor.
>
>Signed-off-by: Eric Piel <eric.piel@tremplin-utc.net>
>--
>