Which cpu-freq module to use for Intel(R) Xeon(R) CPU

Which cpu-freq module to use for Intel(R) Xeon(R) CPU

[Lei Yang]

Dear list,

I'm a newbie on kernel cpu frequency scaling and I'm trying to get this work
on a Intel(R) Xeon(R) CPU workstation. The kernel version is 2.6.11.

So far, I've looked into
/lib/modules/2.6.11/kernel/arch/x86_64/kernel/cpufreq and found four kernel
modules there: acpi-cpufreq.ko  powernow-k8.ko  speedstep-centrino.ko
speedstep-nocona.ko . However, when I tried to install them using modprobe,
they all reported an error like "FATAL: Module acpi_cpufreq.ko not found".
So please give me a hint on the right procedure to follow.

Plus, I read from the kernel cpu-freq page on the supported hardware and
found that "Intel Pentium4/Xeon clock modulation (p4-clockmod)". Does this
mean that I need to install p4-clockmod for my workstation? Interestingly, I
also found on Dave Jones' page the following:

- P4 clock modulation. Note, that this driver does NOT save power. It
inserts 'waits' between clock cycles, so workloads take longer to complete,
but generate less heat whilst doing so.

I got confused, should I be using p4-clockmod or something else if I really
need to save power?

Thanks a lot!!!

Lei

Re: Which cpu-freq module to use for Intel(R) Xeon(R) CPU

[Dave Jones]

On Mon, Jun 18, 2007 at 11:02:29AM -0700, Lei Yang wrote:
 > Dear list,
 > 
 > I'm a newbie on kernel cpu frequency scaling and I'm trying to get this work
 > on a Intel(R) Xeon(R) CPU workstation. The kernel version is 2.6.11.

There have been literally hundreds of changes to the cpufreq drivers
since 2.6.11.  I'll be surprised if anyone really remembers the quirks
of the various drivers in a > two year old kernel.

 > So far, I've looked into
 > /lib/modules/2.6.11/kernel/arch/x86_64/kernel/cpufreq and found four kernel
 > modules there: acpi-cpufreq.ko  powernow-k8.ko  speedstep-centrino.ko
 > speedstep-nocona.ko . However, when I tried to install them using modprobe,
 > they all reported an error like "FATAL: Module acpi_cpufreq.ko not found".
 > So please give me a hint on the right procedure to follow.

if your /proc/cpuinfo flags has 'est', then acpi-cpufreq is the way to
go, unless your BIOS doesn't have correct ACPI tables, in which case
speedstep-centrino is the answer.
In current kernels, speedstep-centrino is deprecated in favour of
acpi-cpufreq (and will disappear completely soon, possibly in .23)

 > Plus, I read from the kernel cpu-freq page on the supported hardware and
 > found that "Intel Pentium4/Xeon clock modulation (p4-clockmod)". Does this
 > mean that I need to install p4-clockmod for my workstation? Interestingly, I
 > also found on Dave Jones' page the following:
 > 
 > - P4 clock modulation. Note, that this driver does NOT save power. It
 > inserts 'waits' between clock cycles, so workloads take longer to complete,
 > but generate less heat whilst doing so.
 > 
 > I got confused, should I be using p4-clockmod or something else if I really
 > need to save power?

As my note reads, you'll be producing less overall heat, but as your workload
runs for a longer period, you're still using the same (possibly more)
amount of power.

	Dave

-- 
http://www.codemonkey.org.uk

Re: Which cpu-freq module to use for Intel(R) Xeon(R) CPU

[markus reichelt]

[-- Attachment #1.1: Type: text/plain, Size: 304 bytes --]

* Dave Jones <davej@redhat.com> wrote:

> In current kernels, speedstep-centrino is deprecated in favour of
> acpi-cpufreq (and will disappear completely soon, possibly in .23)

Any chance that the freq-tables (for Banias) of speedstep-centrino
will survive? Where?

-- 
left blank, right bald

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

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

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

RE: Which cpu-freq module to use for Intel(R) Xeon(R) CPU

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: cpufreq-bounces@lists.linux.org.uk 
>[mailto:cpufreq-bounces@lists.linux.org.uk] On Behalf Of 
>markus reichelt
>Sent: Tuesday, June 19, 2007 8:08 AM
>To: cpufreq@lists.linux.org.uk
>Subject: Re: Which cpu-freq module to use for Intel(R) Xeon(R) CPU
>
>* Dave Jones <davej@redhat.com> wrote:
>
>> In current kernels, speedstep-centrino is deprecated in favour of
>> acpi-cpufreq (and will disappear completely soon, possibly in .23)
>
>Any chance that the freq-tables (for Banias) of speedstep-centrino
>will survive? Where?
>

Table based speedstep will continue to use speedstep-centrino and
all ACPI based speedstep will migrate to acpi-cpufreq.

Thanks,
Venki

Re: Which cpu-freq module to use for Intel(R) Xeon(R) CPU

[Lei Yang]

OK. I upgraded the system to 2.6.18. I can now load the speedstep-centrino
module and used the 'userspace' govener. In
/sys/devices/system/cpu/cpu0/cpufreq/ there are the following files:

affected_cpus     cpuinfo_max_freq  scaling_available_frequencies
scaling_cur_freq  scaling_governor  scaling_min_freq
cpuinfo_cur_freq  cpuinfo_min_freq  scaling_available_governors
scaling_driver    scaling_max_freq  scaling_setspeed

I have the following questions/problems:

1)  I looked into the value of each file.
     cpuinfo_max_freq : 2331000
     cpuinfo_min_freq: 1998000
     scaling_available_frequencies : 2331000 1998000 1998000 1998000 1998000
1998000

Why the available frequencies have multiple 1998000?

2) Since I'm using the userspace govener, I tried 'echo 1998000 >
scaling_setspeed' , then

scaling_setspeed : 1998000

However, cpuinfo_cur_freq is still 2331000. In contrast, /proc/cpuinfo shows
that the frequency is actually changed to 1998.000 MHz. Why are they
inconsistent?

3) Afterwards, I want to change the frequency back to 2331000 by calling
'echo 2331000 > scaling_setspeed'. However, the 'scaling_setspeed' is not
changed and the frequency is still 1998000. I tried this several times with
no luck. Is this a bug in the govener or in the centrino module?

Thanks a lot!!!

Lei

On 6/18/07, Dave Jones <davej@redhat.com> wrote:
>
> On Mon, Jun 18, 2007 at 11:02:29AM -0700, Lei Yang wrote:
> > Dear list,
> >
> > I'm a newbie on kernel cpu frequency scaling and I'm trying to get this
> work
> > on a Intel(R) Xeon(R) CPU workstation. The kernel version is 2.6.11.
>
> There have been literally hundreds of changes to the cpufreq drivers
> since 2.6.11.  I'll be surprised if anyone really remembers the quirks
> of the various drivers in a > two year old kernel.
>
> > So far, I've looked into
> > /lib/modules/2.6.11/kernel/arch/x86_64/kernel/cpufreq and found four
> kernel
> > modules there: acpi-cpufreq.ko  powernow-k8.ko  speedstep-centrino.ko
> > speedstep-nocona.ko . However, when I tried to install them using
> modprobe,
> > they all reported an error like "FATAL: Module acpi_cpufreq.ko not
> found".
> > So please give me a hint on the right procedure to follow.
>
> if your /proc/cpuinfo flags has 'est', then acpi-cpufreq is the way to
> go, unless your BIOS doesn't have correct ACPI tables, in which case
> speedstep-centrino is the answer.
> In current kernels, speedstep-centrino is deprecated in favour of
> acpi-cpufreq (and will disappear completely soon, possibly in .23)
>
> > Plus, I read from the kernel cpu-freq page on the supported hardware and
> > found that "Intel Pentium4/Xeon clock modulation (p4-clockmod)". Does
> this
> > mean that I need to install p4-clockmod for my workstation?
> Interestingly, I
> > also found on Dave Jones' page the following:
> >
> > - P4 clock modulation. Note, that this driver does NOT save power. It
> > inserts 'waits' between clock cycles, so workloads take longer to
> complete,
> > but generate less heat whilst doing so.
> >
> > I got confused, should I be using p4-clockmod or something else if I
> really
> > need to save power?
>
> As my note reads, you'll be producing less overall heat, but as your
> workload
> runs for a longer period, you're still using the same (possibly more)
> amount of power.
>
>         Dave
>
> --
> http://www.codemonkey.org.uk
>

RE: Which cpu-freq module to use for Intel(R) Xeon(R) CPU

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: cpufreq-bounces@lists.linux.org.uk 
>[mailto:cpufreq-bounces@lists.linux.org.uk] On Behalf Of Lei Yang
>Sent: Tuesday, June 19, 2007 2:34 PM
>To: Dave Jones
>Cc: cpufreq@lists.linux.org.uk
>Subject: Re: Which cpu-freq module to use for Intel(R) Xeon(R) CPU
>
>OK. I upgraded the system to 2.6.18. I can now load the 
>speedstep-centrino
>module and used the 'userspace' govener. In
>/sys/devices/system/cpu/cpu0/cpufreq/ there are the following files:

Post 2.6.20 kernel, you should use acpi-cpufreq driver.

>
>affected_cpus     cpuinfo_max_freq  scaling_available_frequencies
>scaling_cur_freq  scaling_governor  scaling_min_freq
>cpuinfo_cur_freq  cpuinfo_min_freq  scaling_available_governors
>scaling_driver    scaling_max_freq  scaling_setspeed
>
>I have the following questions/problems:
>
>1)  I looked into the value of each file.
>     cpuinfo_max_freq : 2331000
>     cpuinfo_min_freq: 1998000
>     scaling_available_frequencies : 2331000 1998000 1998000 
>1998000 1998000
>1998000
>
>Why the available frequencies have multiple 1998000?

This is how BIOSes export it to avoid having dynamic table to support
different CPU models. Later kernels
remove duplicates while displaying the freq. This is just the cosmetic
issue of how things are displayed.

>2) Since I'm using the userspace govener, I tried 'echo 1998000 >
>scaling_setspeed' , then
>
>scaling_setspeed : 1998000
>
>However, cpuinfo_cur_freq is still 2331000. In contrast, 
>/proc/cpuinfo shows
>that the frequency is actually changed to 1998.000 MHz. Why are they
>inconsistent?

scaling_cur_freq must be showing 1998 in this case.
cpuinfo_cur_freq shows the actual freq from hardware, which can be
higher due to some dependent core/thread
(in same package) requesting higher freq. /proc/cpuinfo and
scaling_cur_freq shows kernel cahcned freq for this CPU.

 
>
>3) Afterwards, I want to change the frequency back to 2331000 
>by calling
>'echo 2331000 > scaling_setspeed'. However, the 
>'scaling_setspeed' is not
>changed and the frequency is still 1998000. I tried this 
>several times with
>no luck. Is this a bug in the govener or in the centrino module?
>

Not sure about this. This should change ideally. Will be interesting to
see what *cur_freq shows.
Also try changing freq of all CPUs in a physical package and check.

Thanks,
Venki

Re: Which cpu-freq module to use for Intel(R) Xeon(R) CPU

[Lei Yang]

Venki, Thanks for the fast response!!

I did try to use the acpi-cpufreq module, however I got an error when I
modprobe:

modprobe acpi-cpufreq
FATAL: Error inserting acpi_cpufreq (/lib/modules/2.6.18-
smp-210.1_rc2/kernel/arch/x86_64/kernel/cpufreq/acpi-cpufreq.ko): Device or
resource busy

Any idea what went wrong?

About the last problem, scaling_cur_freq also shows 1998000, which means
that 'echo  2331000 > scaling_setspeed' doesn't have any effect at all.
Also, what do you mean by 'try changing freq of all CPUs in a physical
package and check'?

Thanks again,
Lei


On 6/19/07, Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com> wrote:
>
>
>
> >-----Original Message-----
> >From: cpufreq-bounces@lists.linux.org.uk
> >[mailto:cpufreq-bounces@lists.linux.org.uk] On Behalf Of Lei Yang
> >Sent: Tuesday, June 19, 2007 2:34 PM
> >To: Dave Jones
> >Cc: cpufreq@lists.linux.org.uk
> >Subject: Re: Which cpu-freq module to use for Intel(R) Xeon(R) CPU
> >
> >OK. I upgraded the system to 2.6.18. I can now load the
> >speedstep-centrino
> >module and used the 'userspace' govener. In
> >/sys/devices/system/cpu/cpu0/cpufreq/ there are the following files:
>
> Post 2.6.20 kernel, you should use acpi-cpufreq driver.
>
> >
> >affected_cpus     cpuinfo_max_freq  scaling_available_frequencies
> >scaling_cur_freq  scaling_governor  scaling_min_freq
> >cpuinfo_cur_freq  cpuinfo_min_freq  scaling_available_governors
> >scaling_driver    scaling_max_freq  scaling_setspeed
> >
> >I have the following questions/problems:
> >
> >1)  I looked into the value of each file.
> >     cpuinfo_max_freq : 2331000
> >     cpuinfo_min_freq: 1998000
> >     scaling_available_frequencies : 2331000 1998000 1998000
> >1998000 1998000
> >1998000
> >
> >Why the available frequencies have multiple 1998000?
>
> This is how BIOSes export it to avoid having dynamic table to support
> different CPU models. Later kernels
> remove duplicates while displaying the freq. This is just the cosmetic
> issue of how things are displayed.
>
> >2) Since I'm using the userspace govener, I tried 'echo 1998000 >
> >scaling_setspeed' , then
> >
> >scaling_setspeed : 1998000
> >
> >However, cpuinfo_cur_freq is still 2331000. In contrast,
> >/proc/cpuinfo shows
> >that the frequency is actually changed to 1998.000 MHz. Why are they
> >inconsistent?
>
> scaling_cur_freq must be showing 1998 in this case.
> cpuinfo_cur_freq shows the actual freq from hardware, which can be
> higher due to some dependent core/thread
> (in same package) requesting higher freq. /proc/cpuinfo and
> scaling_cur_freq shows kernel cahcned freq for this CPU.
>
>
> >
> >3) Afterwards, I want to change the frequency back to 2331000
> >by calling
> >'echo 2331000 > scaling_setspeed'. However, the
> >'scaling_setspeed' is not
> >changed and the frequency is still 1998000. I tried this
> >several times with
> >no luck. Is this a bug in the govener or in the centrino module?
> >
>
> Not sure about this. This should change ideally. Will be interesting to
> see what *cur_freq shows.
> Also try changing freq of all CPUs in a physical package and check.
>
> Thanks,
> Venki
>

RE: Which cpu-freq module to use for Intel(R) Xeon(R) CPU

[Pallipadi, Venkatesh]

 


________________________________

	From: Lei Yang [mailto:leiyang@google.com] 
	Sent: Tuesday, June 19, 2007 3:00 PM
	To: Pallipadi, Venkatesh
	Cc: Dave Jones; cpufreq@lists.linux.org.uk
	Subject: Re: Which cpu-freq module to use for Intel(R) Xeon(R)
CPU
	
	
	Venki, Thanks for the fast response!!
	
	I did try to use the acpi-cpufreq module, however I got an error
when I modprobe:
	
	modprobe acpi-cpufreq
	FATAL: Error inserting acpi_cpufreq
(/lib/modules/2.6.18-smp-210.1_rc2/kernel/arch/x86_64/kernel/cpufreq/acp
i-cpufreq.ko ): Device or resource busy
	
	Any idea what went wrong?


[Venki] Yes. This may not work on 2.6.18. If you use 2.6.21 however,
thie above should work.
	
	About the last problem, scaling_cur_freq also shows 1998000,
which means that 'echo  2331000 > scaling_setspeed' doesn't have any
effect at all. Also, what do you mean by 'try changing freq of all CPUs
in a physical package and check'? 

[Venki] On most processors all logical CPUs (cores, threads) share the
same frequency using something called Hardware coordination. That means,
only when all dependent logical CPUs request for a lower freq, they
change the freq. If one logical CPU asks for higer freq and the other
logical CPU which is dependent asks for a lower freq, then both of them
continue to run at higher freq.
I guess on you system you have 2 physical sockets? All logical CPUs
belonging to one socket will be dependent for frequency. So, when you do
setspeed, try echoing for each CPU in the socket and then check whether
the change has taken effect.

Also, if you use ondemand governor, CPU freq should automatically change
based on utilization.

Thanks,
Venki