Re: cpufreq and p4 prescott

Re: cpufreq and p4 prescott

[Dominik Brodowski]

> i have problems scaling down my p4 prescott 2.8 GHz.
You can't scale a prescott, you can only throttle it.

> [ck@holodeck:cpufreq] cat /proc/cpuinfo | grep Mhz
> cpu MHz         : 2807.131
> cpu MHz         : 2807.131
The cpu MHz entry in /proc/cpuinfo is the same for all CPUs, and no reliable
source to detect the current cpu frequency anyway. Use
/sys/devices/system/cpu/cpu0/scaling_cur_freq or even cpuinfo_cur_freq for
that.[*] So p4-clockmod-throttling does work on your p4 prescott.

	Dominik

[*] Available in 2.6.7, hopefully, if Linus merges the latest cpufreq-bk
tree from Dave. It'll be in the next -mm release, though.

Re: cpufreq and p4 prescott

[clemens kurtenbach]

Hi,

>>[ck@holodeck:cpufreq] cat /proc/cpuinfo | grep Mhz
>>cpu MHz         : 2807.131
>>cpu MHz         : 2807.131
> 
> The cpu MHz entry in /proc/cpuinfo is the same for all CPUs, and no reliable
> source to detect the current cpu frequency anyway.  Use

i thought this because on my ibook i can see different MHz
entry's when cpudyn changes the frequence.

> /sys/devices/system/cpu/cpu0/scaling_cur_freq or even cpuinfo_cur_freq for
> that.[*] So p4-clockmod-throttling does work on your p4 prescott.
> 
> 	Dominik
> 
> [*] Available in 2.6.7, hopefully, if Linus merges the latest cpufreq-bk
> tree from Dave. It'll be in the next -mm release, though.

o.k, when i understand you right p4-clockmod-throttling _is working_
on my system, but i can't see this in /sys until Dave Jones
patches are includet. So i patched my 2.6.6 kernel with
cpufreq-2004-05-13.diff.

Now cpuinfo_cur_freq and scaling_cur_freq show changing entry's
when eg powernowd handles the frequence.

The reason why i want to throttle down my prescott is the heat.
Strange is that when the frequence is changed to 350MHz
(after 30min running with 2.8GHz), neither the CPU&System temperature
nor tools that calculate the CPU speed (like gkrellm-x86info)
show a difference to 2.8GHz. All voltages on my system are the
same with 350MHz/2.8GHz, too.

So i'm not sure if throttling does work until now?

thanks,
clee
-- 
moqua [at] gmx.net
moqua [at] kurtenba.ch

Re: cpufreq and p4 prescott

[rutger]

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

On Thu, May 13, 2004 at 11:19:30AM +0200, clemens kurtenbach wrote:
> Hi,
> 
> >>[ck@holodeck:cpufreq] cat /proc/cpuinfo | grep Mhz
> >>cpu MHz         : 2807.131
> >>cpu MHz         : 2807.131
> >
> >The cpu MHz entry in /proc/cpuinfo is the same for all CPUs, and no 
> >reliable
> >source to detect the current cpu frequency anyway.  Use
> 
> i thought this because on my ibook i can see different MHz
> entry's when cpudyn changes the frequence.
> 
> >/sys/devices/system/cpu/cpu0/scaling_cur_freq or even cpuinfo_cur_freq for
> >that.[*] So p4-clockmod-throttling does work on your p4 prescott.
> >
> >	Dominik
> >
> >[*] Available in 2.6.7, hopefully, if Linus merges the latest cpufreq-bk
> >tree from Dave. It'll be in the next -mm release, though.
> 
> o.k, when i understand you right p4-clockmod-throttling _is working_
> on my system, but i can't see this in /sys until Dave Jones
> patches are includet. So i patched my 2.6.6 kernel with
> cpufreq-2004-05-13.diff.
> 
> Now cpuinfo_cur_freq and scaling_cur_freq show changing entry's
> when eg powernowd handles the frequence.
> 
> The reason why i want to throttle down my prescott is the heat.
> Strange is that when the frequence is changed to 350MHz
> (after 30min running with 2.8GHz), neither the CPU&System temperature
> nor tools that calculate the CPU speed (like gkrellm-x86info)
> show a difference to 2.8GHz. All voltages on my system are the
> same with 350MHz/2.8GHz, too.
> 
> So i'm not sure if throttling does work until now?

No, I think something is broken. There is something wrong, but I do
not know what exactly. Maybe other people can help.

Problem #1 is the speed measurement, as you described. As far as I
understand, p4-clockmod delivers the same external clock to the P4,
but work is not done during every clock tick. E.g. when running at
12.5% of the maximum frequency, only one tick in eight something is
done.

The program attached (cpufreq.c) shows the external clock.

Which gives before clock modulation:
Current CPU speed: 2804Mhz
Which is the same as after clock modulation.

Ok, so if it is true that only the work is done part of the ticks,
then all instructions should take more ticks! Therefore, I try to
measure the number of ticks which the 'rdtsc' instruction itself
takes. I take the minimum of 10 runs, to run
instruction-cache-hot. See cpuclockmod.c .

This gives '140' cycles in the pre-modulated phase (including some
overhead) when running on an idle system, and 154 or 161 running on a
loaded system (1 thread busy looping). If clock modulation meant
'skipping ticks', I would expect this number to multiply.

For this at, I measure the amount of work we can do in 0.1second, not
measured in clockticks but in actual work (in this case:
counting). See attachement idlespeed.c .

This gives something like
$ ./idlespeed 
 16721212 17663088 17753061 17735590 17722159 17711258 17736497
 17738416 17285056 16777378 16811129 17754396 17489097 16838288
 16771207 16522451 17607507 17741537 17696223 17711259 17727780
 16207944 17753235 ...

So quite constant.

Ok, now enabling p4-clockmod:

# modprobe p4-clockmod
# cd /sys/devices/system/cpu
# ls -l cpu0/cpufreq/scaling_governor
-rw-r--r--  1 root root 4096 May 13 16:28 scaling_governor
# echo powersave > cpu0/cpufreq/scaling_governor
# ls -l cpu0/cpufreq/scaling_governor
-rw-r--r--  1 root root 0 May 13 16:28 cpu0/cpufreq/scaling_governor

??? Something changed the size of the virtual file. Strange.

idlespeed has been downscaled by a factor 8 (to be expected) now half
of the time:

$ idlespeed
  2335688 2271157 2251869 2365142 2263489 2325059 2279944 2352220
  2409125 2333738 2743530 2282674 2319563 2482246 2293931 2393624
  ....

..but re-running this several times, yields sometimes (50%) different
results!

$ idlespeed
 17419738 17726984 17560937 17575017 17731884 17745776 17640391
 17669128 17576263 17734663 17711101 17741851 17721642 17748703
 ...
 17581598 17680249

This can also be seen by doing ^S/^Q several times; sometimes it
switches. gkrellm indicates that switching is dependant on which
_virtual_ CPU it runs! Virtual CPU0, the hyper-threaded sibling of
CPU1, has been downscaled, but CPU1 has not!

Now it gets even more weird when running 2 idlespeed's simultanously:
the speed is now about 11671640 on both! And ^Sing one of them, lets
the other jump to 2.3M or 17M depending on the virtual processor it
runs on.

Ok, we throttle the other virtual CPU also:

# echo powersave > cpu1/cpufreq/scaling_governor

This doesn't change a thing, which is to be expected since cpufreq
talks to real CPUs. However, Virtual CPU0 maintains to be the slow
CPU, and Virtual CPU1 is the fast one.

Now the frequency hasn't changed: cpufreq still gives 2804Mhz. But the
number of ticks per instruction have also not changed: still about 160
ticks for doing a rtdc()! What's wrong with my reasoning? What is
happening under the hood?

Playing a little more with cpu0 and cpu1, I sometimes can get to a
state where both virtual cpu's are slowed down, but I cannot reproduce
it 100%. And it's quite difficult to get them both back on full-speed
again.

[used kernel: 2.6.6-bk Wed May 12 22:29:41 with SMT scheduler enabled;
preempt enabled; 2.8Ghz Prescott Pentium 4 chip]

Regards,
Rutger.

-- 
Rutger Nijlunsing ---------------------------- rutger ed tux tmfweb nl
never attribute to a conspiracy which can be explained by incompetence
----------------------------------------------------------------------

[-- Attachment #2: cpufreq.c --]
[-- Type: text/plain, Size: 418 bytes --]

/* Measure CPU speed in ticks per second */

#include <stdio.h>
#include <unistd.h>

unsigned long long rdtsc (void) {
  unsigned long long returned;
  asm volatile (" rdtsc " : "=A" (returned));
  return returned;
}

int main(void) {
  unsigned long long prevtime = rdtsc();
  sleep(1);
  unsigned long long newtime = rdtsc();
  printf("Current CPU speed: %.0fMhz\n", (newtime - prevtime) / 1000000.0);
  return 0;
}

[-- Attachment #3: cpuclockmod.c --]
[-- Type: text/plain, Size: 597 bytes --]

/* Measure the number of clock ticks it takes to measure the number of
   clock ticks */

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

unsigned long long rdtsc (void) {
  unsigned long long returned;
  asm volatile (" rdtsc " : "=A" (returned));
  return returned;
}

int main(void) {
  while (1) {
    int j;
    int minimum = (1 << 30);
    for (j = 0; j < 10; j++) {
      unsigned long long elapsed = -rdtsc();
      elapsed += rdtsc();
      minimum = (elapsed < minimum) ? elapsed : minimum;
    }
    printf("%i\n", minimum);
    usleep(100000); /* 10Hz */
  }
  return 0;
}

[-- Attachment #4: idlespeed.c --]
[-- Type: text/plain, Size: 602 bytes --]

/* Count the number of busy loops we can do in 0.1sec. */

#include <signal.h>
#include <stdio.h>
#include <sys/time.h>
#include <sys/types.h>
#include <unistd.h>

int interrupt = 0;

void handler(int signal) {
  interrupt = 1;
}

int main(void) {
  if (fork() != 0) {
    signal(SIGALRM, handler);
    while(1) {
      long long counter = 0;
      interrupt = 0;
      while (!interrupt) counter++;
      printf("%9llu ", counter);
      fflush(stdout);
    }
  } else {
    int pid = getppid();
    while (1) {
      usleep(100000); /* Wake up parent at 10Hz */
      kill(pid, SIGALRM);
    }
  }
}

Re: cpufreq and p4 prescott

[Dominik Brodowski]

>>>[ck@holodeck:cpufreq] cat /proc/cpuinfo | grep Mhz
>>>cpu MHz         : 2807.131
>>>cpu MHz         : 2807.131
>> 
>> The cpu MHz entry in /proc/cpuinfo is the same for all CPUs, and no
>> reliable
>> source to detect the current cpu frequency anyway.  Use
>
> i thought this because on my ibook i can see different MHz
> entry's when cpudyn changes the frequence.

Well, on UP kernels cpu_khz can be and is changed by the cpufreq subsystem
-- on SMP kernels, it's impossible as cpu_khz is _one_ value and different
SMP CPUs may be put to different speeds [not really valid for
HyperThreading, but for real SMP, yes...]

> The reason why i want to throttle down my prescott is the heat.
> Strange is that when the frequence is changed to 350MHz
> (after 30min running with 2.8GHz), neither the CPU&System temperature

No surprise on that. I guess you weren't using 100% of the CPU? The CPU
is put into an idle state when it is unused anyways, and that idle state
consumes quite exactly as much power as when the CPU is throttled. So, as
long as the CPU isn't used 100%, you won't see a difference in power
consumption == heat generation between p4-clockmod throttling and idling.
p4-clockmod _only_ helps if the CPU needs to be limited to provide less than
100% processing power _or_ if the idling algorithm doesn't work.

> nor tools that calculate the CPU speed (like gkrellm-x86info)
> show a difference to 2.8GHz.

No surprise on that, too. x86info uses the TSC (time stamp counter) to 
determine the CPU frequency, and on P4s the TSC runs at a constant rate
even if the frequency is throttled. Always remember the difference between
scaling and throttling:

x is a CPU clock tick, * is a tick where nothing happens, but the TSC runs
as normal:

normal operations: x x x x x x x x x x x x x x x x x x x x x x x x 

throttling:        x x x x * * * * x x x x * * * * x x x x * * * *

scaling:           x   x   x   x   x   x   x   x   x   x   x   x  

> All voltages on my system are the same with 350MHz/2.8GHz, too.

'cause throttling doesn't lead to voltage scaling. You need a _voltage
sclaing capable_ CPU and chipset and system environment (motherboard, BIOS,
...) for that.

> So i'm not sure if throttling does work until now?

It does, AFAICS.

	Dominik

Re: cpufreq and p4 prescott

[Dominik Brodowski]

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

> > So i'm not sure if throttling does work until now?
> 
> No, I think something is broken. There is something wrong, but I do
> not know what exactly. Maybe other people can help.
>
> Problem #1 is the speed measurement, as you described. As far as I
> understand, p4-clockmod delivers the same external clock to the P4,
> but work is not done during every clock tick. E.g. when running at
> 12.5% of the maximum frequency, only one tick in eight something is
> done.

Almost. The Time Stamp Counter (inside the CPU) works with a constant
frequency, but only at e.g. each eigth tick the other parts of the CPU do
some work.

> Ok, so if it is true that only the work is done part of the ticks,
> then all instructions should take more ticks! Therefore, I try to
> measure the number of ticks which the 'rdtsc' instruction itself
> takes. I take the minimum of 10 runs, to run
> instruction-cache-hot. See cpuclockmod.c .
> 
> This gives '140' cycles in the pre-modulated phase (including some
> overhead) when running on an idle system, and 154 or 161 running on a
> loaded system (1 thread busy looping). If clock modulation meant
> 'skipping ticks', I would expect this number to multiply.

Not necessarily. It's not really every eigth tick where work is done, but
more like 800 ticks where work is done, then 5600 ticks pause, and so on --
the frequency is somewhere in the docs, I forgot the exact value... So I'm
not 100% convinced the measurements you've done do show something broken.

> This doesn't change a thing, which is to be expected since cpufreq
> talks to real CPUs.

It should, something _is_ broken in this regard [and I'm working on it, just
had sent a RFC to the cpufreq mailing list...]. Maybe this causes some
strangeness, especially if you run a userspace cpufreq tool -- but maybe the
p4-clockmod hardware is even more strange than I thought it to be, and is
per _virtual_ CPU.

Can you please apply the latest cpufreq snapshot from
http://www.codemonkey.org.uk/projects/bitkeeper/cpufreq/
, then the attached patch, and switch the CPU frequencies of both (virtual)
CPUs around a bit, and after each switch, 
cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
cat /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq

and check whether the values are the same you wrote into the specific CPU's
scaling_setspeed [if using the userspace governor] file?

Many thanks,
	Dominik

[-- Attachment #2: test_p4 --]
[-- Type: text/plain, Size: 1018 bytes --]

diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c linux/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c
--- linux-original/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c	2004-05-13 16:52:02.000000000 +0200
+++ linux/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c	2004-05-13 19:36:47.629852152 +0200
@@ -68,11 +68,7 @@
 	cpus_allowed = current->cpus_allowed;
 
 	/* only run on CPU to be set, or on its sibling */
-#ifdef CONFIG_SMP
-	affected_cpu_map = cpu_sibling_map[cpu];
-#else
 	affected_cpu_map = cpumask_of_cpu(cpu);
-#endif
 	set_cpus_allowed(current, affected_cpu_map);
         BUG_ON(!cpu_isset(smp_processor_id(), affected_cpu_map));
 
@@ -273,11 +269,7 @@
 
 	/* only run on CPU to be set, or on its sibling */
 	cpus_allowed = current->cpus_allowed;
-#ifdef CONFIG_SMP
-        affected_cpu_map = cpu_sibling_map[cpu];
-#else
         affected_cpu_map = cpumask_of_cpu(cpu);
-#endif
 	set_cpus_allowed(current, affected_cpu_map);
         BUG_ON(!cpu_isset(smp_processor_id(), affected_cpu_map));
 

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

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

Re: cpufreq and p4 prescott

[Dominik Brodowski]

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

> > So i'm not sure if throttling does work until now?
> 
> No, I think something is broken. There is something wrong, but I do
> not know what exactly. Maybe other people can help.
>
> Problem #1 is the speed measurement, as you described. As far as I
> understand, p4-clockmod delivers the same external clock to the P4,
> but work is not done during every clock tick. E.g. when running at
> 12.5% of the maximum frequency, only one tick in eight something is
> done.

Almost. The Time Stamp Counter (inside the CPU) works with a constant
frequency, but only at e.g. each eigth tick the other parts of the CPU do
some work.

> Ok, so if it is true that only the work is done part of the ticks,
> then all instructions should take more ticks! Therefore, I try to
> measure the number of ticks which the 'rdtsc' instruction itself
> takes. I take the minimum of 10 runs, to run
> instruction-cache-hot. See cpuclockmod.c .
> 
> This gives '140' cycles in the pre-modulated phase (including some
> overhead) when running on an idle system, and 154 or 161 running on a
> loaded system (1 thread busy looping). If clock modulation meant
> 'skipping ticks', I would expect this number to multiply.

Not necessarily. It's not really every eigth tick where work is done, but
more like 800 ticks where work is done, then 5600 ticks pause, and so on --
the frequency is somewhere in the docs, I forgot the exact value... So I'm
not 100% convinced the measurements you've done do show something broken.

> This doesn't change a thing, which is to be expected since cpufreq
> talks to real CPUs.

It should, something _is_ broken in this regard [and I'm working on it, just
had sent a RFC to the cpufreq mailing list...]. Maybe this causes some
strangeness, especially if you run a userspace cpufreq tool -- but maybe the
p4-clockmod hardware is even more strange than I thought it to be, and is
per _virtual_ CPU.

Can you please apply the latest cpufreq snapshot from
http://www.codemonkey.org.uk/projects/bitkeeper/cpufreq/
, then the attached patch, and switch the CPU frequencies of both (virtual)
CPUs around a bit, and after each switch, 
cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
cat /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq

and check whether the values are the same you wrote into the specific CPU's
scaling_setspeed [if using the userspace governor] file?

Many thanks,
	Dominik

[-- Attachment #2: test_p4 --]
[-- Type: text/plain, Size: 1018 bytes --]

diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c linux/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c
--- linux-original/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c	2004-05-13 16:52:02.000000000 +0200
+++ linux/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c	2004-05-13 19:36:47.629852152 +0200
@@ -68,11 +68,7 @@
 	cpus_allowed = current->cpus_allowed;
 
 	/* only run on CPU to be set, or on its sibling */
-#ifdef CONFIG_SMP
-	affected_cpu_map = cpu_sibling_map[cpu];
-#else
 	affected_cpu_map = cpumask_of_cpu(cpu);
-#endif
 	set_cpus_allowed(current, affected_cpu_map);
         BUG_ON(!cpu_isset(smp_processor_id(), affected_cpu_map));
 
@@ -273,11 +269,7 @@
 
 	/* only run on CPU to be set, or on its sibling */
 	cpus_allowed = current->cpus_allowed;
-#ifdef CONFIG_SMP
-        affected_cpu_map = cpu_sibling_map[cpu];
-#else
         affected_cpu_map = cpumask_of_cpu(cpu);
-#endif
 	set_cpus_allowed(current, affected_cpu_map);
         BUG_ON(!cpu_isset(smp_processor_id(), affected_cpu_map));
 

Re: cpufreq and p4 prescott

[rutger]

> > Problem #1 is the speed measurement, as you described. As far as I
> > understand, p4-clockmod delivers the same external clock to the P4,
> > but work is not done during every clock tick. E.g. when running at
> > 12.5% of the maximum frequency, only one tick in eight something is
> > done.
> 
> Almost. The Time Stamp Counter (inside the CPU) works with a constant
> frequency, but only at e.g. each eigth tick the other parts of the CPU do
> some work.

That's what I meant.

> 
> > Ok, so if it is true that only the work is done part of the ticks,
> > then all instructions should take more ticks! Therefore, I try to
> > measure the number of ticks which the 'rdtsc' instruction itself
> > takes. I take the minimum of 10 runs, to run
> > instruction-cache-hot. See cpuclockmod.c .
> > 
> > This gives '140' cycles in the pre-modulated phase (including some
> > overhead) when running on an idle system, and 154 or 161 running on a
> > loaded system (1 thread busy looping). If clock modulation meant
> > 'skipping ticks', I would expect this number to multiply.
> 
> Not necessarily. It's not really every eigth tick where work is done, but
> more like 800 ticks where work is done, then 5600 ticks pause, and so on --
> the frequency is somewhere in the docs, I forgot the exact value... So I'm
> not 100% convinced the measurements you've done do show something broken.

Ah, ok! This makes the measurement next to impossible. Unless we
generate instructions of ~900 ticks, which should takes 900 + 5600
ticks in case of modulated clock, and 900 ticks in case of
non-modulated clock. Something to try...

> > This doesn't change a thing, which is to be expected since cpufreq
> > talks to real CPUs.
> 
> It should, something _is_ broken in this regard [and I'm working on it, just
> had sent a RFC to the cpufreq mailing list...]. Maybe this causes some
> strangeness, especially if you run a userspace cpufreq tool -- but maybe the
> p4-clockmod hardware is even more strange than I thought it to be, and is
> per _virtual_ CPU.
> 
> Can you please apply the latest cpufreq snapshot from
> http://www.codemonkey.org.uk/projects/bitkeeper/cpufreq/
> , then the attached patch, and switch the CPU frequencies of both (virtual)
> CPUs around a bit, and after each switch, 
> cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
> cat /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq
> 
> and check whether the values are the same you wrote into the specific CPU's
> scaling_setspeed [if using the userspace governor] file?

Ok, I applied both patches.

root@localhost /sys/devices/system/cpu/cpu0/cpufreq# cat scaling_available_frequencies 
350000 700000 1050000 1400000 1750000 2100000 2450000 2800000 
root@localhost /sys/devices/system/cpu/cpu0/cpufreq# for f in `cat scaling_available_frequencies `; do echo $f >scaling_setspeed ; cat scaling_cur_freq ; done
350000
700000
1050000
1400000
1750000
2100000
2450000
2800000

Seems to work...

Some remarks:
 - scaling_governor and scaling_setspeed get length 0 after echo-ing to.
   Other files keep the virtual size of 4096.

 - scaling seems to work reliable now _if_ I repeat the scaling for
   each virtual processor and make them the same. It doesn't do
   anything useful if I only set cpu0.

 - It's far more repeatable now. If I set the speed of virtual CPU0,
   it really sets it, and only sets CPU0, and not like previously only
   in 50% of the cases or so.


However, what's the use of p4-clockmod if it doesn't have impact on
the temperature and the power consumption of the CPU?

My Asus p4p800 seems to be able to set several voltages and frequences
in the BIOS; can those be set runtime? And/or is there any
documentation on this? This would make for a much more useful driver.

Thanks!


> 
> Many thanks,
> 	Dominik

> diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c linux/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c
> --- linux-original/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c	2004-05-13 16:52:02.000000000 +0200
> +++ linux/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c	2004-05-13 19:36:47.629852152 +0200
> @@ -68,11 +68,7 @@
>  	cpus_allowed = current->cpus_allowed;
>  
>  	/* only run on CPU to be set, or on its sibling */
> -#ifdef CONFIG_SMP
> -	affected_cpu_map = cpu_sibling_map[cpu];
> -#else
>  	affected_cpu_map = cpumask_of_cpu(cpu);
> -#endif
>  	set_cpus_allowed(current, affected_cpu_map);
>          BUG_ON(!cpu_isset(smp_processor_id(), affected_cpu_map));
>  
> @@ -273,11 +269,7 @@
>  
>  	/* only run on CPU to be set, or on its sibling */
>  	cpus_allowed = current->cpus_allowed;
> -#ifdef CONFIG_SMP
> -        affected_cpu_map = cpu_sibling_map[cpu];
> -#else
>          affected_cpu_map = cpumask_of_cpu(cpu);
> -#endif
>  	set_cpus_allowed(current, affected_cpu_map);
>          BUG_ON(!cpu_isset(smp_processor_id(), affected_cpu_map));
>  


-- 
Rutger Nijlunsing ---------------------------- rutger ed tux tmfweb nl
never attribute to a conspiracy which can be explained by incompetence
----------------------------------------------------------------------

Re: cpufreq and p4 prescott

[Dominik Brodowski]

On Fri, May 14, 2004 at 11:47:51PM +0200, rutger@nospam.com wrote:
> > Not necessarily. It's not really every eigth tick where work is done, but
> > more like 800 ticks where work is done, then 5600 ticks pause, and so on --
> > the frequency is somewhere in the docs, I forgot the exact value... So I'm
> > not 100% convinced the measurements you've done do show something broken.
> 
> Ah, ok! This makes the measurement next to impossible. Unless we
> generate instructions of ~900 ticks, which should takes 900 + 5600
> ticks in case of modulated clock, and 900 ticks in case of
> non-modulated clock. Something to try...

As I said, I forgot the actual frequency, so 800 ticks is a guess...

> root@localhost /sys/devices/system/cpu/cpu0/cpufreq# cat scaling_available_frequencies 
> 350000 700000 1050000 1400000 1750000 2100000 2450000 2800000 
> root@localhost /sys/devices/system/cpu/cpu0/cpufreq# for f in `cat scaling_available_frequencies `; do echo $f >scaling_setspeed ; cat scaling_cur_freq ; done
> 350000
> 700000
> 1050000
> 1400000
> 1750000
> 2100000
> 2450000
> 2800000
> 
> Seems to work...
Hm, could you please do 

# for f in `cat scaling_available_frequencies `; do echo $f >scaling_setspeed ; cat cpuinfo_cur_freq ; cat /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq ; done

instead? scaling_cur_freq doesn't give as useful _debug_ results as
cpuinfo_cur_freq, and it's important to get it for _both_ siblings after
_each_ change

> Some remarks:
>  - scaling_governor and scaling_setspeed get length 0 after echo-ing to.
>    Other files keep the virtual size of 4096.
That's some sort of sysfs "handling" - don't know about details and
consequences.

>  - scaling seems to work reliable now _if_ I repeat the scaling for
>    each virtual processor and make them the same. It doesn't do
>    anything useful if I only set cpu0.

Maybe because much/more work is done by the other sibling then... however,
without the test above [cpuinfo_cur_freq for both siblings] I can't say
much, I'm afraid.

> However, what's the use of p4-clockmod if it doesn't have impact on
> the temperature and the power consumption of the CPU?

The use of the p4-clockmod driver is that it puts the CPU into a low-power
state -- it only has thermal and power consequences, however, if either the
"idling" does not work, or the processor load is higher than the frequency
the CPU is put into by p4-clockmod.

> My Asus p4p800 seems to be able to set several voltages and frequences
> in the BIOS; can those be set runtime?

No. This is motherboard-specific. The P4 does not support _voltage scaling_,
i.e. runtime voltage adjustment based on current power needs. It also
doesn't support _frequency scaling_, just (thermal) throttling.

> And/or is there any
> documentation on this? This would make for a much more useful driver.

Unfortunately, p4-clockmod isn't really all that useful -- but that's
because the hardware doesn't support voltage and/or frequency scaling.

	Dominik

Re: cpufreq and p4 prescott

[Dominik Brodowski]

On Fri, May 14, 2004 at 11:47:51PM +0200, rutger@nospam.com wrote:
> > Not necessarily. It's not really every eigth tick where work is done, but
> > more like 800 ticks where work is done, then 5600 ticks pause, and so on --
> > the frequency is somewhere in the docs, I forgot the exact value... So I'm
> > not 100% convinced the measurements you've done do show something broken.
> 
> Ah, ok! This makes the measurement next to impossible. Unless we
> generate instructions of ~900 ticks, which should takes 900 + 5600
> ticks in case of modulated clock, and 900 ticks in case of
> non-modulated clock. Something to try...

As I said, I forgot the actual frequency, so 800 ticks is a guess...

> root@localhost /sys/devices/system/cpu/cpu0/cpufreq# cat scaling_available_frequencies 
> 350000 700000 1050000 1400000 1750000 2100000 2450000 2800000 
> root@localhost /sys/devices/system/cpu/cpu0/cpufreq# for f in `cat scaling_available_frequencies `; do echo $f >scaling_setspeed ; cat scaling_cur_freq ; done
> 350000
> 700000
> 1050000
> 1400000
> 1750000
> 2100000
> 2450000
> 2800000
> 
> Seems to work...
Hm, could you please do 

# for f in `cat scaling_available_frequencies `; do echo $f >scaling_setspeed ; cat cpuinfo_cur_freq ; cat /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq ; done

instead? scaling_cur_freq doesn't give as useful _debug_ results as
cpuinfo_cur_freq, and it's important to get it for _both_ siblings after
_each_ change

> Some remarks:
>  - scaling_governor and scaling_setspeed get length 0 after echo-ing to.
>    Other files keep the virtual size of 4096.
That's some sort of sysfs "handling" - don't know about details and
consequences.

>  - scaling seems to work reliable now _if_ I repeat the scaling for
>    each virtual processor and make them the same. It doesn't do
>    anything useful if I only set cpu0.

Maybe because much/more work is done by the other sibling then... however,
without the test above [cpuinfo_cur_freq for both siblings] I can't say
much, I'm afraid.

> However, what's the use of p4-clockmod if it doesn't have impact on
> the temperature and the power consumption of the CPU?

The use of the p4-clockmod driver is that it puts the CPU into a low-power
state -- it only has thermal and power consequences, however, if either the
"idling" does not work, or the processor load is higher than the frequency
the CPU is put into by p4-clockmod.

> My Asus p4p800 seems to be able to set several voltages and frequences
> in the BIOS; can those be set runtime?

No. This is motherboard-specific. The P4 does not support _voltage scaling_,
i.e. runtime voltage adjustment based on current power needs. It also
doesn't support _frequency scaling_, just (thermal) throttling.

> And/or is there any
> documentation on this? This would make for a much more useful driver.

Unfortunately, p4-clockmod isn't really all that useful -- but that's
because the hardware doesn't support voltage and/or frequency scaling.

	Dominik

Re: cpufreq and p4 prescott

[rutger]

> > Ah, ok! This makes the measurement next to impossible. Unless we
> > generate instructions of ~900 ticks, which should takes 900 + 5600
> > ticks in case of modulated clock, and 900 ticks in case of
> > non-modulated clock. Something to try...
> 
> As I said, I forgot the actual frequency, so 800 ticks is a guess...

The only thing I could find in Intel's documentation is the max. time
of throttling is 3 microseconds (p.67; 5.2.1 of Prescott
datasheet). So this 3 microseconds should correspond to 5600 ticks or
so...

> 
> > root@localhost /sys/devices/system/cpu/cpu0/cpufreq# cat scaling_available_frequencies 
> > 350000 700000 1050000 1400000 1750000 2100000 2450000 2800000 
> > root@localhost /sys/devices/system/cpu/cpu0/cpufreq# for f in `cat scaling_available_frequencies `; do echo $f >scaling_setspeed ; cat scaling_cur_freq ; done
> > 350000
> > 700000
> > 1050000
> > 1400000
> > 1750000
> > 2100000
> > 2450000
> > 2800000
> > 
> > Seems to work...
> Hm, could you please do 
> 
> # for f in `cat scaling_available_frequencies `; do echo $f >scaling_setspeed ; cat cpuinfo_cur_freq ; cat /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq ; done
> 
> instead? scaling_cur_freq doesn't give as useful _debug_ results as
> cpuinfo_cur_freq, and it's important to get it for _both_ siblings after
> _each_ change

/sys/devices/system/cpu/cpu0/cpufreq# for f in `cat scaling_available_frequencies `; do echo $f >scaling_setspeed ; cat cpuinfo_cur_freq ; cat /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq;  done
350000
2800000
700000
2800000
1050000
2800000
1400000
2800000
1750000
2800000
2100000
2800000
2450000
2800000
2800000
2800000

..so it has only effect on the same sibbling, not the other. That's
what I meant with 'repeat scaling for each virtual processor'.

> >  - scaling seems to work reliable now _if_ I repeat the scaling for
> >    each virtual processor and make them the same. It doesn't do
> >    anything useful if I only set cpu0.
> 
> Maybe because much/more work is done by the other sibling then... however,
> without the test above [cpuinfo_cur_freq for both siblings] I can't say
> much, I'm afraid.

That's true. I can set the freq. of each virtual CPU. Probably not
very useful, and even confusing. And if we keep this, the scheduler
should be told about the speed differences of both (virtual)
processors.

> > However, what's the use of p4-clockmod if it doesn't have impact on
> > the temperature and the power consumption of the CPU?
> 
> The use of the p4-clockmod driver is that it puts the CPU into a low-power
> state -- it only has thermal and power consequences, however, if either the
> "idling" does not work, or the processor load is higher than the frequency
> the CPU is put into by p4-clockmod.

I saw several sleep states in which the processor can reside (like
when using the 'hlt' instruction) like S3; would those help?

> 
> > My Asus p4p800 seems to be able to set several voltages and frequences
> > in the BIOS; can those be set runtime?
> 
> No. This is motherboard-specific. The P4 does not support _voltage scaling_,
> i.e. runtime voltage adjustment based on current power needs. It also
> doesn't support _frequency scaling_, just (thermal) throttling.

I know this is not P4 specific, but motherboard specific, but do
you know of modules which use motherboard specific knowledge to scale
the processor? If the BIOS can do it, so should we be able to do it.

Regards,
Rutger.

-- 
Rutger Nijlunsing ---------------------------- rutger ed tux tmfweb nl
never attribute to a conspiracy which can be explained by incompetence
----------------------------------------------------------------------

Re: cpufreq and p4 prescott

[Dominik Brodowski]

On Sat, May 15, 2004 at 12:52:01PM +0200, rutger@nospam.com wrote:
> > > Ah, ok! This makes the measurement next to impossible. Unless we
> > > generate instructions of ~900 ticks, which should takes 900 + 5600
> > > ticks in case of modulated clock, and 900 ticks in case of
> > > non-modulated clock. Something to try...
> > 
> > As I said, I forgot the actual frequency, so 800 ticks is a guess...
> 
> The only thing I could find in Intel's documentation is the max. time
> of throttling is 3 microseconds (p.67; 5.2.1 of Prescott
> datasheet). So this 3 microseconds should correspond to 5600 ticks or
> so...

Can't find it in the datasheets right now, but did find an interesting
comment in section 13.15.3 of 24547212.pdf which explains the strange
behaviour we're seeing.

> ..so it has only effect on the same sibbling, not the other. That's
> what I meant with 'repeat scaling for each virtual processor'.

This is so strange... but it is what's to be found in said section in the
datasheet. It says both logical CPUs need to be set identically so that it
works "properly", i.e. as expected.

> That's true. I can set the freq. of each virtual CPU. Probably not
> very useful, and even confusing. And if we keep this,

I think we should not keep it; I'll prepare a patch soon.

> the scheduler
> should be told about the speed differences of both (virtual)
> processors.

On (real) SMP systems this is an issue; but even more on SMP systems where 
true frequency and voltage scaling is done. 

> > > However, what's the use of p4-clockmod if it doesn't have impact on
> > > the temperature and the power consumption of the CPU?
> > 
> > The use of the p4-clockmod driver is that it puts the CPU into a low-power
> > state -- it only has thermal and power consequences, however, if either the
> > "idling" does not work, or the processor load is higher than the frequency
> > the CPU is put into by p4-clockmod.
> 
> I saw several sleep states in which the processor can reside (like
> when using the 'hlt' instruction) like S3; would those help?

If you mean C3, then that's very good. ACPI C-States are "idling" -- ACPI
S-States (like S3) are for "suspend to ram/disk"

> I know this is not P4 specific, but motherboard specific, but do
> you know of modules which use motherboard specific knowledge to scale
> the processor?
No.
> If the BIOS can do it, so should we be able to do it.

Dynamic frequency scaling is (probably) way different from setting a
frequency at boot (which is what the BIOS does). Timing issues, settling
times, etc. are way too complicated, AFAICS. Even trying to do this might
result in severe non-recoverable hardware failures.

	Dominik

Re: cpufreq and p4 prescott

[Dominik Brodowski]

On Sat, May 15, 2004 at 12:52:01PM +0200, rutger@nospam.com wrote:
> > > Ah, ok! This makes the measurement next to impossible. Unless we
> > > generate instructions of ~900 ticks, which should takes 900 + 5600
> > > ticks in case of modulated clock, and 900 ticks in case of
> > > non-modulated clock. Something to try...
> > 
> > As I said, I forgot the actual frequency, so 800 ticks is a guess...
> 
> The only thing I could find in Intel's documentation is the max. time
> of throttling is 3 microseconds (p.67; 5.2.1 of Prescott
> datasheet). So this 3 microseconds should correspond to 5600 ticks or
> so...

Can't find it in the datasheets right now, but did find an interesting
comment in section 13.15.3 of 24547212.pdf which explains the strange
behaviour we're seeing.

> ..so it has only effect on the same sibbling, not the other. That's
> what I meant with 'repeat scaling for each virtual processor'.

This is so strange... but it is what's to be found in said section in the
datasheet. It says both logical CPUs need to be set identically so that it
works "properly", i.e. as expected.

> That's true. I can set the freq. of each virtual CPU. Probably not
> very useful, and even confusing. And if we keep this,

I think we should not keep it; I'll prepare a patch soon.

> the scheduler
> should be told about the speed differences of both (virtual)
> processors.

On (real) SMP systems this is an issue; but even more on SMP systems where 
true frequency and voltage scaling is done. 

> > > However, what's the use of p4-clockmod if it doesn't have impact on
> > > the temperature and the power consumption of the CPU?
> > 
> > The use of the p4-clockmod driver is that it puts the CPU into a low-power
> > state -- it only has thermal and power consequences, however, if either the
> > "idling" does not work, or the processor load is higher than the frequency
> > the CPU is put into by p4-clockmod.
> 
> I saw several sleep states in which the processor can reside (like
> when using the 'hlt' instruction) like S3; would those help?

If you mean C3, then that's very good. ACPI C-States are "idling" -- ACPI
S-States (like S3) are for "suspend to ram/disk"

> I know this is not P4 specific, but motherboard specific, but do
> you know of modules which use motherboard specific knowledge to scale
> the processor?
No.
> If the BIOS can do it, so should we be able to do it.

Dynamic frequency scaling is (probably) way different from setting a
frequency at boot (which is what the BIOS does). Timing issues, settling
times, etc. are way too complicated, AFAICS. Even trying to do this might
result in severe non-recoverable hardware failures.

	Dominik

Re: cpufreq and p4 prescott

[Rutger Nijlunsing]

> > The only thing I could find in Intel's documentation is the max. time
> > of throttling is 3 microseconds (p.67; 5.2.1 of Prescott
> > datasheet). So this 3 microseconds should correspond to 5600 ticks or
> > so...
> 
> Can't find it in the datasheets right now, but did find an interesting
> comment in section 13.15.3 of 24547212.pdf which explains the strange
> behaviour we're seeing.

Hm, 13.16.3 in my version, but indeed: all logical processors should
be put asleep in the same way ;)

> 
> > I know this is not P4 specific, but motherboard specific, but do
> > you know of modules which use motherboard specific knowledge to scale
> > the processor?
> No.
> > If the BIOS can do it, so should we be able to do it.
> 
> Dynamic frequency scaling is (probably) way different from setting a
> frequency at boot (which is what the BIOS does). Timing issues, settling
> times, etc. are way too complicated, AFAICS. Even trying to do this might
> result in severe non-recoverable hardware failures.

Probably true for some motherboards, but Asus got a WinXP program
called 'AiBooster' which is a program to under/overclock from -50% to
+33% runtime (butt-ugly UI can be seen in
http://www.asuscom.de/pub/ASUS/mb/sock478/p4p800/AIBooster_u.pdf). Could
Wine be used (given the right permissions) to run or disect such a
utility to make underclocking reality under Linux?

*hopeful* Or has Asus released the specification of its motherboard?

-- 
Rutger Nijlunsing ---------------------------- rutger ed tux tmfweb nl
never attribute to a conspiracy which can be explained by incompetence
----------------------------------------------------------------------

cpufreq and p4 prescott

[clemens kurtenbach]

Hi,

i have problems scaling down my p4 prescott 2.8 GHz.
In the /sys -tree all seems to be ok:

[ck@holodeck:cpufreq] pwd
/sys/devices/system/cpu/cpu0/cpufreq

[ck@holodeck:cpufreq] ls -1
cpuinfo_max_freq
cpuinfo_min_freq
scaling_available_frequencies
scaling_available_governors
scaling_driver
scaling_governor
scaling_max_freq
scaling_min_freq
scaling_setspeed

[ck@holodeck:cpufreq] cat *
2800000
350000
350000 700000 1050000 1400000 1750000 2100000 2450000 2800000
powersave userspace performance
p4-clockmod
userspace
2800000
350000
350000

[ck@holodeck:cpufreq] cat /proc/cpuinfo | grep Mhz
cpu MHz         : 2807.131
cpu MHz         : 2807.131

As you can see tools like cpudyn or powernowd successfully
change the entry in scaling_setspeed (also for cpu1),
but the real cpu clock stays at 2.8GHz ?

The cpudyn doc sais there's support for 'Intel Pentium 4, Intel Xeon'
CPU's, but is there support for p4 prescott ?

Has annyone here successfully scaled down a prescott ?

regards,
clee
-- 
moqua [at] gmx.net
moqua [at] kurtenba.ch