cpufreq Archive on lore.kernel.org
 help / color / mirror / Atom feed
* RE: [PATCH] transition latency of speedstep-ich (third try)
@ 2005-11-28 22:19 Pallipadi, Venkatesh
  2005-11-28 23:35 ` Eric Piel
  0 siblings, 1 reply; 13+ messages in thread
From: Pallipadi, Venkatesh @ 2005-11-28 22:19 UTC (permalink / raw)
  To: Mattia Dongili, Eric Piel; +Cc: davej, Dominik Brodowski, cpufreq

 

>-----Original Message-----
>From: Mattia Dongili [mailto:malattia@linux.it] 
>Sent: Monday, November 28, 2005 2:13 PM
>To: Eric Piel
>Cc: Pallipadi, Venkatesh; davej@redhat.com; Dominik Brodowski; 
>cpufreq@lists.linux.org.uk
>Subject: Re: [PATCH] transition latency of speedstep-ich (third try)
>
>On Sat, Nov 26, 2005 at 11:40:20PM +0100, Eric Piel wrote:
>> 05.10.2005 22:39, Pallipadi, Venkatesh wrote/a écrit:
>[...]
>> >Do you have ACPI PM timer on your system? May be we can measure the 
>> >latency using that. 
>> >
>> Hello,
>> 
>> Sorry for the looonnnggg delay of the reply. I've finally 
>found time to 
>> hunt for the PM timer on my computer, found it, and kludged 
>> speedstep-ich to read it :-) For verification and completeness, the 
>> patch is attached. (the PM timer address is hard-coded, it has to be 
>> changed before running it on another system, it's indicated 
>at boot in 
>> dmesg).
>> 
>> So the results are quite interesting and confirm your expectations, 
>> Venki. After few hours with the ondemand governor, I checked 
>the logs 
>> and the transition latency seems very stable: around 735 to 
>742 PM timer 
>> ticks (~206 us). So indeed, 100us of transition latency was quite 
>> under-estimating it!
>
>So here's some measurement on my P3M (seems a little faster than yours
>in switching):
>
>processor	: 0
>vendor_id	: GenuineIntel
>cpu family	: 6
>model		: 11
>model name	: Intel(R) Pentium(R) III Mobile CPU      1000MHz
>stepping	: 1
>cpu MHz		: 994.394
>cache size	: 512 KB
>fdiv_bug	: no
>hlt_bug		: no
>f00f_bug	: no
>coma_bug	: no
>fpu		: yes
>fpu_exception	: yes
>cpuid level	: 2
>wp		: yes
>flags		: fpu vme de pse tsc msr pae mce cx8 apic sep 
>mtrr pge mca cmov pat pse36 mmx fxsr sse
>bogomips	: 1991.49
>
>
>cpufrequtils 0.3: cpufreq-info (C) Dominik Brodowski 2004
>Report errors and bugs to linux@brodo.de, please.
>analyzing CPU 0:
>  driver: speedstep-ich
>  CPUs which need to switch frequency at the same time: 0
>  hardware limits: 732 MHz - 998 MHz
>  available frequency steps: 998 MHz, 732 MHz
>  available cpufreq governors: powersave, performance
>  current policy: frequency should be within 732 MHz and 998 MHz.
>                  The governor "performance" may decide which 
>speed to use
>                  within this range.
>  current CPU frequency is 998 MHz.
>
>Some stats while switching from the 2 available frequencies while
>doing some random compile and/or disk intensive operation:
>
>| min->MAX                      | MAX->min
>+---------                      +---------
>| 709 PM cicles - occurences 1  | 709 PM cicles - occurences 1
>| 710 PM cicles - occurences 1  | 710 PM cicles - occurences 5
>| 711 PM cicles - occurences 3  | 711 PM cicles - occurences 2
>| 712 PM cicles - occurences 2  | 712 PM cicles - occurences 3
>| 713 PM cicles - occurences 9  | 713 PM cicles - occurences 3
>| 714 PM cicles - occurences 1  | 714 PM cicles - occurences 3
>| 715 PM cicles - occurences 4  | 715 PM cicles - occurences 3
>| 716 PM cicles - occurences 5  | 716 PM cicles - occurences 6
>| 717 PM cicles - occurences 5  | 717 PM cicles - occurences 6
>| 718 PM cicles - occurences 2  | 718 PM cicles - occurences 5
>| 719 PM cicles - occurences 6  | 719 PM cicles - occurences 4
>| 720 PM cicles - occurences 1  | 720 PM cicles - occurences 2
>| 721 PM cicles - occurences 3  | 721 PM cicles - occurences 1
>| 722 PM cicles - occurences 4  | 722 PM cicles - occurences 4
>| 723 PM cicles - occurences 1  | 723 PM cicles - occurences 2
>| 724 PM cicles - occurences 3  | 724 PM cicles - occurences 1
>
>PM cicles weighted average: 716.412
>TSC cicles weighted average: 6009.422
>
>(you don't want to see the perl script that generated it) :)
>
>> Now back to the original problem, from those measurements, 
>which time 
>> should we put as the maximal transition latency for 
>speedstep-ich? Do 
>> you think we can simply put something like 300us and that's 
>it? Maybe we 
>
>I just build speedstep-ich with transition_latency = 250
>I'll let you know how it goes. Are you interested?
>
>> could distinguish between PIII and P4 ? It would require someone to 
>> rerun the measurement on a P4 hardware. Do we need to take 
>into account 
>> as a parameter the CPU frequency?
>
>Maybe it's already been discussed, but how bad would be trying to
>measure transition latency at runtime?
>


Yes. I was thinking the same thing. As this latency may be different on P3-M and P4-M, may be we can do with a measurement at boot time and use it, rather than hardcoding these values. However, I think we will have to do that by using gettimeofday or some such higherlevel call instead of using pmtimer as pmtimer may not be available on all systems at all times. Otherwise, we may end up all sort of pmtimer/pit/hpet timer code in this driver.

Thanks,
Venki

^ permalink raw reply	[flat|nested] 13+ messages in thread
* RE: [PATCH] transition latency of speedstep-ich (third try)
@ 2005-10-05 20:39 Pallipadi, Venkatesh
  2005-11-26 22:40 ` Eric Piel
  0 siblings, 1 reply; 13+ messages in thread
From: Pallipadi, Venkatesh @ 2005-10-05 20:39 UTC (permalink / raw)
  To: Eric Piel; +Cc: davej, Dominik Brodowski, cpufreq


>-----Original Message-----
>From: Eric Piel [mailto:Eric.Piel@tremplin-utc.net] 
>Sent: Thursday, September 29, 2005 3:06 PM
>>>
>>>As it's very different from the numbers you got, I wonder if 
>I mistook 
>>>somewhere ?
>>>
>> 
>> 
>> I don't have any numbers with Coppermine or P4-M. Probably the reason
>> For low numbers is TSC itself stops at certain times during 
>this whole
>> Operation. And it will also run at slower frequency once you 
>change the
>> Freq (On coppermine). 6uS is too low in my opinion. We may not be 
>> measuring correctly here.
>Could it happen that on a P4M the TSC doesn't stop? Then maybe someone 
>with such a harware could try? Otherwise, what do you suggest 
>to obtain 
>the maximum transition latency? Take 500uS and multiply by the 
>number of 
>I/O in the code ?
>
>Eric
>

Do you have ACPI PM timer on your system? May be we can measure the 
latency using that. 

Thanks,
Venki

^ permalink raw reply	[flat|nested] 13+ messages in thread
* RE: [PATCH] transition latency of speedstep-ich (third try)
@ 2005-09-28 23:53 Pallipadi, Venkatesh
  2005-09-29 22:06 ` Eric Piel
  0 siblings, 1 reply; 13+ messages in thread
From: Pallipadi, Venkatesh @ 2005-09-28 23:53 UTC (permalink / raw)
  To: Eric Piel; +Cc: davej, Dominik Brodowski, cpufreq


>-----Original Message-----
>From: Eric Piel [mailto:Eric.Piel@tremplin-utc.net] 
>> Eric,
>> Can you put rdtsc's around these in/out on your system and 
>check how long do they really take. On P4M, rdtsc should be 
>running all the time other than the Cpu being in deep_sleep 
>state. That should give us some idea about the SMM latency.
>> 
>Ok, I've just done it. It's on a P3 coppermine though (not a P4M). So 
>I've measure the difference of tsc before and after the in/out 
>instructions (not included the local_irq_*()). The patch is 
>attached for 
>double check (or if someone wants to try on another CPU). The values 
>seem very small compare to the 500uS you mentioned.
>
>After few minutes with ondemand governor, there was a log like this:
>Sep 28 23:30:32 circle kernel: cpufreq transition took 4862 cycles
>Sep 28 23:30:33 circle kernel: cpufreq transition took 4473 cycles
>Sep 28 23:30:33 circle kernel: cpufreq transition took 4836 cycles
>Sep 28 23:30:35 circle kernel: cpufreq transition took 4723 cycles
>Sep 28 23:30:35 circle kernel: cpufreq transition took 5640 cycles
>Sep 28 23:30:48 circle kernel: cpufreq transition took 4515 cycles
>Sep 28 23:30:48 circle kernel: cpufreq transition took 4904 cycles
>Sep 28 23:31:02 circle kernel: cpufreq transition took 4286 cycles
>Sep 28 23:31:02 circle kernel: cpufreq transition took 4607 cycles
>Sep 28 23:31:03 circle kernel: cpufreq transition took 4279 cycles
>Sep 28 23:31:03 circle kernel: cpufreq transition took 4605 cycles
>Sep 28 23:31:04 circle kernel: cpufreq transition took 4694 cycles
>Sep 28 23:31:04 circle kernel: cpufreq transition took 4605 cycles
>Sep 28 23:31:13 circle kernel: cpufreq transition took 4683 cycles
>Sep 28 23:31:14 circle kernel: cpufreq transition took 4676 cycles
>Sep 28 23:31:14 circle kernel: cpufreq transition took 4515 cycles
>Sep 28 23:31:15 circle kernel: cpufreq transition took 4522 cycles
>
>Maximum I've seen is 5640 cycles, minimum is about 4200c. My CPU is 
>clocked 1GHz so the result can be easily summarized to a maximum of 
>about 6uS.
>
>As it's very different from the numbers you got, I wonder if I mistook 
>somewhere ?
>

I don't have any numbers with Coppermine or P4-M. Probably the reason
For low numbers is TSC itself stops at certain times during this whole
Operation. And it will also run at slower frequency once you change the
Freq (On coppermine). 6uS is too low in my opinion. We may not be 
measuring correctly here.

Thanks,
Venki

^ permalink raw reply	[flat|nested] 13+ messages in thread
* RE: [PATCH] transition latency of speedstep-ich (third try)
@ 2005-09-28  1:26 Pallipadi, Venkatesh
  2005-09-28 21:38 ` Eric Piel
  0 siblings, 1 reply; 13+ messages in thread
From: Pallipadi, Venkatesh @ 2005-09-28  1:26 UTC (permalink / raw)
  To: Eric Piel; +Cc: davej, Dominik Brodowski, cpufreq



Great work! Getting those useful numbers form those documents :).

I think the 100uS and 50uS looks proper from what the documents describe. However, there is one factor that we are missing though. Speedstep-ich uses IO ports to initiate these transitions. Right? These IO port accesses trap into BIOS code which actually initiaites the trasntion. And this trap into BIOS code happens through SMM. And whenvever SMM's are involved I have seen latencies of upto 500uS! And in speedstep_ich:speedstep_set_state(), I see more than one in/out instructions. So, it can easily be higher than this.

I think we need to add a guestimate for SMM latency number as well.

Eric,
Can you put rdtsc's around these in/out on your system and check how long do they really take. On P4M, rdtsc should be running all the time other than the Cpu being in deep_sleep state. That should give us some idea about the SMM latency.

Thanks,
Venki

>-----Original Message-----
>From: Eric Piel [mailto:Eric.Piel@tremplin-utc.net] 
>Sent: Monday, September 19, 2005 3:35 PM
>To: Pallipadi, Venkatesh
>Cc: Dominik Brodowski; davej@redhat.com; cpufreq@lists.linux.org.uk
>Subject: Re: [PATCH] transition latency of speedstep-ich (third try)
>
>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);
>
>

^ permalink raw reply	[flat|nested] 13+ messages in thread
* [PATCH] support for CPUFREQ_ETERNAL drivers by the ondemand governor
@ 2005-02-06 22:33 Eric Piel
  2005-02-09 19:15 ` Dominik Brodowski
  0 siblings, 1 reply; 13+ messages in thread
From: Eric Piel @ 2005-02-06 22:33 UTC (permalink / raw)
  To: Venkatesh Pallipadi, Jun Nakajima; +Cc: cpufreq

[-- 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

^ permalink raw reply	[flat|nested] 13+ messages in thread
end of thread, other threads:[~2005-11-29  7:48 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-11-28 22:19 [PATCH] transition latency of speedstep-ich (third try) Pallipadi, Venkatesh
2005-11-28 23:35 ` Eric Piel
2005-11-28 23:48   ` Mattia Dongili
2005-11-29  7:48     ` Mattia Dongili
  -- strict thread matches above, loose matches on Subject: below --
2005-10-05 20:39 Pallipadi, Venkatesh
2005-11-26 22:40 ` Eric Piel
2005-11-28 22:12   ` Mattia Dongili
2005-09-28 23:53 Pallipadi, Venkatesh
2005-09-29 22:06 ` Eric Piel
2005-10-14 15:19   ` Stefan Seyfried
2005-09-28  1:26 Pallipadi, Venkatesh
2005-09-28 21:38 ` Eric Piel
2005-02-06 22:33 [PATCH] support for CPUFREQ_ETERNAL drivers by the ondemand governor Eric Piel
2005-02-09 19:15 ` Dominik Brodowski
2005-03-06 17:06   ` [PATCH] transition latency of speedstep-ich Eric Piel
     [not found]     ` <20050307182137.GB24559@isilmar.linta.de>
     [not found]       ` <432DD8DD.3090805@tremplin-utc.net>
     [not found]         ` <20050919101843.GA13041@isilmar.linta.de>
2005-09-19 22:35           ` [PATCH] transition latency of speedstep-ich (third try) Eric Piel

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