[PATCHSET] 0/3 Dynamic cpufreq governor and updates to ACPI P-state driver

[PATCHSET] 0/3 Dynamic cpufreq governor and updates to ACPI P-state driver

[Pallipadi, Venkatesh]

Hi,

Most of the latest CPUs (laptop CPUs in particular) have feature 
which enable very low latency P-state transitions 
(like Enhanced Speedstep Technology-EST). Using this feature, 
we can have a lightweight in kernel cpufreq governor, 
to vary CPU frequency depending on the CPU usage. The 
advantage being low power consumption and also cooler laptops.

Another related change is enhancing the current ACPI P-state 
driver to handle:
EST (and MSR based P-state transitions), make the driver SMP 
aware and introduce HT coordination in the driver (HT siblings 
share the same CPU frequency).

The patches that follow this mail addresses the above issues. 
They are against 2.6-test7 kernel. Many thanks to Dominik for 
his comments and suggestions.

The patches will work on all laptops with EST technology 
(Centrino) and also on any other system that supports low 
latency frequency change. 

Reviews/testing of patches are most welcome.

Thanks,
-Venkatesh


Patches are split as follows:

Patch 1/3: Changes to ACPI P-state driver, to handle MSR 
based transitions frequency transitions and make the driver 
SMP aware.

Patch 2/3: Introduce HT-synchronization in the ACPI P-state 
Driver, to take care of shared CPU frequency between HT siblings.

Patch 3/3: New dynamic cpufreq driver (called 
DemandBasedSwitch driver), which periodically monitors CPU 
usage and changes the CPU frequency based on the demand.

[PATCHSET] 0/3 Dynamic cpufreq governor and updates to ACPI P-state driver

[Pallipadi, Venkatesh]

Hi,

Most of the latest CPUs (laptop CPUs in particular) have feature 
which enable very low latency P-state transitions 
(like Enhanced Speedstep Technology-EST). Using this feature, 
we can have a lightweight in kernel cpufreq governor, 
to vary CPU frequency depending on the CPU usage. The 
advantage being low power consumption and also cooler laptops.

Another related change is enhancing the current ACPI P-state 
driver to handle:
EST (and MSR based P-state transitions), make the driver SMP 
aware and introduce HT coordination in the driver (HT siblings 
share the same CPU frequency).

The patches that follow this mail addresses the above issues. 
They are against 2.6-test7 kernel. Many thanks to Dominik for 
his comments and suggestions.

The patches will work on all laptops with EST technology 
(Centrino) and also on any other system that supports low 
latency frequency change. 

Reviews/testing of patches are most welcome.

Thanks,
-Venkatesh


Patches are split as follows:

Patch 1/3: Changes to ACPI P-state driver, to handle MSR 
based transitions frequency transitions and make the driver 
SMP aware.

Patch 2/3: Introduce HT-synchronization in the ACPI P-state 
Driver, to take care of shared CPU frequency between HT siblings.

Patch 3/3: New dynamic cpufreq driver (called 
DemandBasedSwitch driver), which periodically monitors CPU 
usage and changes the CPU frequency based on the demand.

Re: [PATCHSET] 0/3 Dynamic cpufreq governor and updates to ACPI P-state driver

[Måns Rullgård]

"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com> writes:

> Most of the latest CPUs (laptop CPUs in particular) have feature 
> which enable very low latency P-state transitions 
> (like Enhanced Speedstep Technology-EST). Using this feature, 
> we can have a lightweight in kernel cpufreq governor, 
> to vary CPU frequency depending on the CPU usage. The 
> advantage being low power consumption and also cooler laptops.

So, how does this work?  I'd like to be able to set minimum and
maximum clock frequencies to allow, and CPU utilization thresholds at
which to switch frequencies.  Is that possible, or is it work yet to
be done?  Adjustable polling interval would also be nice.

> The patches will work on all laptops with EST technology 
> (Centrino) and also on any other system that supports low 
> latency frequency change. 

Does Pentium 4 M work?

-- 
Måns Rullgård
mru@kth.se

Re: [PATCHSET] 0/3 Dynamic cpufreq governor and updates to ACPI P-state driver

[Måns Rullgård]

"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com> writes:

> Most of the latest CPUs (laptop CPUs in particular) have feature 
> which enable very low latency P-state transitions 
> (like Enhanced Speedstep Technology-EST). Using this feature, 
> we can have a lightweight in kernel cpufreq governor, 
> to vary CPU frequency depending on the CPU usage. The 
> advantage being low power consumption and also cooler laptops.

So, how does this work?  I'd like to be able to set minimum and
maximum clock frequencies to allow, and CPU utilization thresholds at
which to switch frequencies.  Is that possible, or is it work yet to
be done?  Adjustable polling interval would also be nice.

> The patches will work on all laptops with EST technology 
> (Centrino) and also on any other system that supports low 
> latency frequency change. 

Does Pentium 4 M work?

-- 
Måns Rullgård
mru@kth.se

Re: [PATCHSET] 0/3 Dynamic cpufreq governor and updates to ACPI P-state driver

[Måns Rullgård]

"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com> writes:

> Most of the latest CPUs (laptop CPUs in particular) have feature 
> which enable very low latency P-state transitions 
> (like Enhanced Speedstep Technology-EST). Using this feature, 
> we can have a lightweight in kernel cpufreq governor, 
> to vary CPU frequency depending on the CPU usage. The 
> advantage being low power consumption and also cooler laptops.

So, I took this thing for a spin, but it didn't work at all.  I loaded
the module, and did "echo demandbased > /sys/.../scaling_governor".
This echo never returned, and the keyboard locked up.  After a little
while, the fan started running at full speed.  I managed to cut and
paste into an xterm and start top, which showed nothing unusual.  I
could shut down and reboot normally.

-- 
Måns Rullgård
mru@kth.se

Re: [PATCHSET] 0/3 Dynamic cpufreq governor and updates to ACPI P-state driver

[Måns Rullgård]

mru@kth.se (Måns Rullgård) writes:

>> Most of the latest CPUs (laptop CPUs in particular) have feature 
>> which enable very low latency P-state transitions 
>> (like Enhanced Speedstep Technology-EST). Using this feature, 
>> we can have a lightweight in kernel cpufreq governor, 
>> to vary CPU frequency depending on the CPU usage. The 
>> advantage being low power consumption and also cooler laptops.
>
> So, I took this thing for a spin, but it didn't work at all.  I loaded
> the module, and did "echo demandbased > /sys/.../scaling_governor".
> This echo never returned, and the keyboard locked up.  After a little
> while, the fan started running at full speed.  I managed to cut and
> paste into an xterm and start top, which showed nothing unusual.  I
> could shut down and reboot normally.

I might add that this was on an Asus M2400E laptop.

/proc/cpuinfo:
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 15
model		: 2
model name	: Mobile Intel(R) Pentium(R) 4 - M CPU 1.80GHz
stepping	: 7
cpu MHz		: 2070.179
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 sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid
bogomips	: 4087.80

-- 
Måns Rullgård
mru@kth.se

Re: [PATCHSET] 0/3 Dynamic cpufreq governor and updates to ACPI P-state driver

[Alexander Bokovoy]

On Tue, Oct 21, 2003 at 12:57:15PM +0200, M?ns Rullg?rd wrote:
> "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com> writes:
> 
> > Most of the latest CPUs (laptop CPUs in particular) have feature 
> > which enable very low latency P-state transitions 
> > (like Enhanced Speedstep Technology-EST). Using this feature, 
> > we can have a lightweight in kernel cpufreq governor, 
> > to vary CPU frequency depending on the CPU usage. The 
> > advantage being low power consumption and also cooler laptops.
> 
> So, I took this thing for a spin, but it didn't work at all.  I loaded
> the module, and did "echo demandbased > /sys/.../scaling_governor".
> This echo never returned, and the keyboard locked up.  After a little
> while, the fan started running at full speed.  I managed to cut and
> paste into an xterm and start top, which showed nothing unusual.  I
> could shut down and reboot normally.
I applied these patches to stock 2.6.0-test8 and selected 'demandbased' as
default governor. In result, everything worked from the very beginning, my
Centrino-based system went to 600MHz and was upping when load was going
higher during compilation or disk access but went down when load was
lowering. So it works well for me.
-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [PATCHSET] 0/3 Dynamic cpufreq governor and updates to ACPI P-state driver

[Måns Rullgård]

Alexander Bokovoy <ab@altlinux.org> writes:

>> > Most of the latest CPUs (laptop CPUs in particular) have feature 
>> > which enable very low latency P-state transitions 
>> > (like Enhanced Speedstep Technology-EST). Using this feature, 
>> > we can have a lightweight in kernel cpufreq governor, 
>> > to vary CPU frequency depending on the CPU usage. The 
>> > advantage being low power consumption and also cooler laptops.
>> 
>> So, I took this thing for a spin, but it didn't work at all.  I loaded
>> the module, and did "echo demandbased > /sys/.../scaling_governor".
>> This echo never returned, and the keyboard locked up.  After a little
>> while, the fan started running at full speed.  I managed to cut and
>> paste into an xterm and start top, which showed nothing unusual.  I
>> could shut down and reboot normally.
> I applied these patches to stock 2.6.0-test8 and selected 'demandbased' as
> default governor. In result, everything worked from the very beginning, my
> Centrino-based system went to 600MHz and was upping when load was going
> higher during compilation or disk access but went down when load was
> lowering. So it works well for me.

What's your /proc/cpuinfo?  Mine says

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 15
model		: 2
model name	: Mobile Intel(R) Pentium(R) 4 - M CPU 1.80GHz
stepping	: 7
cpu MHz		: 2069.912
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 sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid
bogomips	: 4087.80



-- 
Måns Rullgård
mru@kth.se

Re: [PATCHSET] 0/3 Dynamic cpufreq governor and updates to ACPI P-state driver

[Dominik Brodowski]

On Tue, Oct 21, 2003 at 10:25:10AM +0200, Måns Rullgård wrote:
> "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com> writes:
> 
> > Most of the latest CPUs (laptop CPUs in particular) have feature 
> > which enable very low latency P-state transitions 
> > (like Enhanced Speedstep Technology-EST). Using this feature, 
> > we can have a lightweight in kernel cpufreq governor, 
> > to vary CPU frequency depending on the CPU usage. The 
> > advantage being low power consumption and also cooler laptops.
> 
> So, how does this work?  I'd like to be able to set minimum and
> maximum clock frequencies to allow

echo "..." > /sys/devices/system/cpu/0/cpufreq/scaling_min_speed
echo "..." > /sys/devices/system/cpu/0/cpufreq/scaling_max_speed

>, and CPU utilization thresholds at which to switch frequencies.

select the demandbased governor

echo "demandbased" > /sys/devices/system/cpu/0/cpufreq/scaling_governor

and wait for the inclusion of a sysfs interface to the demandbased governor
which lets you override the current switching frequencies of 20% and 80%.

> Is that possible, or is it work yet to be done? 

Almost done.

> Adjustable polling interval would also be nice.

Should also be adaptable by sysfs. This sysfs interface really will be a
very useful addition, but it's not top priority.
 
	Dominik

Re: [PATCHSET] 0/3 Dynamic cpufreq governor and updates to ACPI P-state driver

[Alexander Bokovoy]

On Tue, Oct 21, 2003 at 10:39:16PM +0200, M?ns Rullg?rd wrote:
> Alexander Bokovoy <ab@altlinux.org> writes:
> 
> >> > Most of the latest CPUs (laptop CPUs in particular) have feature 
> >> > which enable very low latency P-state transitions 
> >> > (like Enhanced Speedstep Technology-EST). Using this feature, 
> >> > we can have a lightweight in kernel cpufreq governor, 
> >> > to vary CPU frequency depending on the CPU usage. The 
> >> > advantage being low power consumption and also cooler laptops.
> >> 
> >> So, I took this thing for a spin, but it didn't work at all.  I loaded
> >> the module, and did "echo demandbased > /sys/.../scaling_governor".
> >> This echo never returned, and the keyboard locked up.  After a little
> >> while, the fan started running at full speed.  I managed to cut and
> >> paste into an xterm and start top, which showed nothing unusual.  I
> >> could shut down and reboot normally.
> > I applied these patches to stock 2.6.0-test8 and selected 'demandbased' as
> > default governor. In result, everything worked from the very beginning, my
> > Centrino-based system went to 600MHz and was upping when load was going
> > higher during compilation or disk access but went down when load was
> > lowering. So it works well for me.
> 
> What's your /proc/cpuinfo?  Mine says
> 
> processor	: 0
> vendor_id	: GenuineIntel
> cpu family	: 15
> model		: 2
> model name	: Mobile Intel(R) Pentium(R) 4 - M CPU 1.80GHz
> stepping	: 7
> cpu MHz		: 2069.912
> 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 sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid
> bogomips	: 4087.80
As I said, it is Centrino-based, with 1.3GHz Pentium M:

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 9
model name	: Intel(R) Pentium(R) M processor 1300MHz
stepping	: 5
cpu MHz		: 597.592
cache size	: 1024 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 mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 tm
bogomips	: 1192.75

Note the current CPU MHz sticking to ~600 -- it is cpufreq's result.

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [PATCHSET] 0/3 Dynamic cpufreq governor and updates to ACPI P-state driver

[Måns Rullgård]

Alexander Bokovoy <ab@altlinux.org> writes:

>> What's your /proc/cpuinfo?  Mine says
>> 
>> processor	: 0
>> vendor_id	: GenuineIntel
>> cpu family	: 15
>> model	: 2
>> model name	: Mobile Intel(R) Pentium(R) 4 - M CPU 1.80GHz
>> stepping	: 7

> As I said, it is Centrino-based, with 1.3GHz Pentium M:
>
> processor	: 0
> vendor_id	: GenuineIntel
> cpu family	: 6
> model		: 9
> model name	: Intel(R) Pentium(R) M processor 1300MHz
> stepping	: 5

So, mine won't work, or what?

-- 
Måns Rullgård
mru@kth.se

Re: [PATCHSET] 0/3 Dynamic cpufreq governor and updates to ACPI P-state driver

[Alexander Bokovoy]

On Tue, Oct 21, 2003 at 11:37:16PM +0200, M?ns Rullg?rd wrote:
> Alexander Bokovoy <ab@altlinux.org> writes:
> 
> >> What's your /proc/cpuinfo?  Mine says
> >> 
> >> processor	: 0
> >> vendor_id	: GenuineIntel
> >> cpu family	: 15
> >> model	: 2
> >> model name	: Mobile Intel(R) Pentium(R) 4 - M CPU 1.80GHz
> >> stepping	: 7
> 
> > As I said, it is Centrino-based, with 1.3GHz Pentium M:
> >
> > processor	: 0
> > vendor_id	: GenuineIntel
> > cpu family	: 6
> > model		: 9
> > model name	: Intel(R) Pentium(R) M processor 1300MHz
> > stepping	: 5
> 
> So, mine won't work, or what?
If you can boot into 2.4.22 or .23pre with ACPI enabled and can see
/proc/acpi/processor/CPU0/performance, then your processor should be
supported by speedstep-ich or speedstep-piix4 modules (don't know which
one exactly).
-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [PATCHSET] 0/3 Dynamic cpufreq governor and updates to ACPI P-state driver

[Måns Rullgård]

Alexander Bokovoy <ab@altlinux.org> writes:

> If you can boot into 2.4.22 or .23pre with ACPI enabled and can see

I haven't booted a 2.4 kernel in a long time.

> /proc/acpi/processor/CPU0/performance, then your processor should be
> supported by speedstep-ich or speedstep-piix4 modules (don't know which
> one exactly).

I was using p4-clockmod.  Doesn't that work?

-- 
Måns Rullgård
mru@kth.se

Re: [PATCHSET] 0/3 Dynamic cpufreq governor and updates to ACPI P-state driver

[Mukesh Rajan]

>> one processor, this theory isn't true for all processors. And dynamic
>> power management should work best _for all processors_.

This is too much of a generalization. By simply reducing the frequency
there only will be reduction in instantaneous power consumed by the
processor. There is no arguing that. But objective is to save energy.
Whether there will be energy savings or not, does not depend much on
processor, but _also_ on the underlying OS, the scheduler, the nature of
application etc etc or in other words the system as a whole.

I think i did see some good numbers in the past for mpeg decoder on XScale
patform with eCOS (static scheduling). But on arm-linux on an IPAQ I saw
nothing when I tried varying the processor voltage with load changes.
Maybe my modeling of load, frequency selection algorithm were not sound
enough, I dunno. I did'nt work on that project long enough.

Comments like "Noted that frequency changed" and "date sheet said so and
so" are not much convincing as actual numbers would.

Regards,
Mukesh


On Mon, Nov 03, 2003 at 07:21:34PM -0800, Jan Rychter wrote:
> >>>>> "Len" == Len Brown writes:
>  >> I have done some measurements on a Toshiba S7/290LNKW, which has a
>  >> 900MHz Pentium-M. The results have been posted to this list a while
>  >> ago -- the most surprising one being that the Pentium-M in that
>  >> machine seemed to always consume the same amount of power when idle,
>  >> independent of operating frequency.  The frequency only made a
>  >> difference when the CPU was actually doing something (or when I made
>  >> it not use the C3 state by loading usb-uhci).
> 
>  Len> Probably the cpu is running HLT in the idle loop, so the power
>  Len> consumption there would not vary with MHz.
> 
> Oh -- well, that's exactly what I wanted to check. It seems it does vary
> for speedstepped Pentium-III Mobile, according to my measurements,
> that's why I was surprised.
> 
> This should influence the design of dynamic power management -- if the
> CPU is already idle, there is no point in slowing it down. It only makes
> sense to change the frequency when we're actually doing something.

This assumption is at least partly wrong. Pentium-III Mobile datasheets
clearly show that the power usage when doing nothing varies up to 50%
dependand on the frequency setting. So even if it is no measurable effect
on
one processor, this theory isn't true for all processors. And dynamic
power management should work best _for all processors_.

	Dominik

Re: [PATCHSET] 0/3 Dynamic cpufreq governor and updates to ACPI P-state driver

[Dominik Brodowski]

On Mon, Nov 03, 2003 at 07:21:34PM -0800, Jan Rychter wrote:
> >>>>> "Len" == Len Brown writes:
>  >> I have done some measurements on a Toshiba S7/290LNKW, which has a
>  >> 900MHz Pentium-M. The results have been posted to this list a while
>  >> ago -- the most surprising one being that the Pentium-M in that
>  >> machine seemed to always consume the same amount of power when idle,
>  >> independent of operating frequency.  The frequency only made a
>  >> difference when the CPU was actually doing something (or when I made
>  >> it not use the C3 state by loading usb-uhci).
> 
>  Len> Probably the cpu is running HLT in the idle loop, so the power
>  Len> consumption there would not vary with MHz.
> 
> Oh -- well, that's exactly what I wanted to check. It seems it does vary
> for speedstepped Pentium-III Mobile, according to my measurements,
> that's why I was surprised.
> 
> This should influence the design of dynamic power management -- if the
> CPU is already idle, there is no point in slowing it down. It only makes
> sense to change the frequency when we're actually doing something.

This assumption is at least partly wrong. Pentium-III Mobile datasheets
clearly show that the power usage when doing nothing varies up to 50%
dependand on the frequency setting. So even if it is no measurable effect on
one processor, this theory isn't true for all processors. And dynamic
power management should work best _for all processors_.

	Dominik

Re: [PATCHSET] 0/3 Dynamic cpufreq governor and updates to ACPI P-state driver

[Jan Rychter]

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

>>>>> "Len" == Len Brown writes:
 >> I have done some measurements on a Toshiba S7/290LNKW, which has a
 >> 900MHz Pentium-M. The results have been posted to this list a while
 >> ago -- the most surprising one being that the Pentium-M in that
 >> machine seemed to always consume the same amount of power when idle,
 >> independent of operating frequency.  The frequency only made a
 >> difference when the CPU was actually doing something (or when I made
 >> it not use the C3 state by loading usb-uhci).

 Len> Probably the cpu is running HLT in the idle loop, so the power
 Len> consumption there would not vary with MHz.

Oh -- well, that's exactly what I wanted to check. It seems it does vary
for speedstepped Pentium-III Mobile, according to my measurements,
that's why I was surprised.

This should influence the design of dynamic power management -- if the
CPU is already idle, there is no point in slowing it down. It only makes
sense to change the frequency when we're actually doing something.

--J.

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

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

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

RE: [PATCHSET] 0/3 Dynamic cpufreq governor and updates to ACPI P-state driver

[Brown, Len]

> I have done some measurements on a Toshiba S7/290LNKW,
> which has a 900MHz Pentium-M. The results have been posted to 
> this list a while ago -- the most surprising one being that the 
> Pentium-M in that machine seemed to always consume the same
> amount of power when idle, independent of operating frequency.
> The frequency only made a difference
> when the CPU was actually doing something (or when I made it 
> not use the C3 state by loading usb-uhci).

Probably the cpu is running HLT in the idle loop,
so the power consumption there would not vary with MHz.

Cheers,
-Len

Re: [PATCHSET] 0/3 Dynamic cpufreq governor and updates to ACPI P-state driver

[Jan Rychter]

>>>>> "Venkatesh" == Venkatesh Pallipadi writes:
 Venkatesh> I do not have any performance numbers taken from actual
 Venkatesh> probes. We have seen in our testing that the the frequency
 Venkatesh> does change based on the cpu usage.  For example, on a
 Venkatesh> Centrino system,
 Venkatesh> - frequency will be lowest when system is idle
 Venkatesh> - frequency will be somewhere in the mid-range when you run
 Venkatesh>   single app like mp3/mpeg player
 Venkatesh> - frequency will be maximum when you run multiple apps
 Venkatesh> And with the kind of power savings that comes with these
 Venkatesh> frequency changes, this behaviour results in longer battery
 Venkatesh> life. However, as yet I do not have any numbers to quantify
 Venkatesh> this gain, mainly because I do not have any setup where I
 Venkatesh> can measure actual power.
[...]

Interesting. I have done some measurements on a Toshiba S7/290LNKW,
which has a 900MHz Pentium-M. The results have been posted to this list
a while ago -- the most surprising one being that the Pentium-M in that
machine seemed to always consume the same amount of power when idle,
independent of operating frequency. The frequency only made a difference
when the CPU was actually doing something (or when I made it not use the
C3 state by loading usb-uhci).

Another interesting result was that in general, my P-III based laptop
has lower power consumption than the Centrino-based one. Runs against
the Centrino advertising campaign.

My measurements were done using the ACPI battery status and overall
seemed to make a lot of sense, except for this little detail. Can
anybody from Intel confirm that this is the way it is supposed to be?

--J.

Re: [PATCHSET] 0/3 Dynamic cpufreq governor and updates to ACPI P-state driver

[Todd Poynor]

> These numbers, which are attached, 
> would probably roughly correspond to a cpufreq-based setup...

Oops, maybe HTML attachments are stripped from the list; see 
http://dynamicpower.sourceforge.net/dpm-centrino.html for the data, 
sorry about that,

-- 
Todd

Re: [PATCHSET] 0/3 Dynamic cpufreq governor and updates to ACPI P-state driver

[Todd Poynor]

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

On Wed, 2003-10-22 at 20:21, Pallipadi, Venkatesh wrote:

>And with the kind of power savings that comes with these frequency
>changes, this behaviour 
>results in  longer battery life. However, as yet I do not have any
>numbers to quantify this gain, 
>mainly because I do not have any setup where I can measure actual power.

I measured amps consumed by a 1.4GHz Centrino notebook model running a 
similar power management system called Dynamic Power Management 
http://dynamicpower.sourceforge.net, which leverages code from the 
speedstep-centrino cpufreq driver by Jeremy Fitzhardinge.  DPM is set to 
run the system at full power when running a process and at minimal power 
when idle (using scheduler hooks).  These numbers, which are attached, 
would probably roughly correspond to a cpufreq-based setup on the same 
platform that modified the CPU speed and voltage very quickly in 
response to process scheduling activity.  I may perform some analysis of 
more dynamic applications that more evenly divide their time between 
active and idle in the near future, in case there is any interest in this.

Amps consumed should be a good predictor of expected battery life, 
independent of the vagaries of any particular battery.  The expensive 
scopemeter used for the attached measurements isn't really necessary, by 
the way; a $130 multimeter that averages DC amps, placed in series 
between the DC transformer and the notebook, should do fine.  In case 
this helps,

-- 
Todd

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

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

Re: [PATCHSET] 0/3 Dynamic cpufreq governor and updates to ACPI P-state driver

[Ducrot Bruno]

On Thu, Oct 23, 2003 at 10:29:37AM +0200, Arjan van de Ven wrote:
> On Thu, Oct 23, 2003 at 11:24:01AM +0300, Alexander Bokovoy wrote:
> > On Thu, Oct 23, 2003 at 10:19:44AM +0200, Arjan van de Ven wrote:
> > > On Wed, 2003-10-22 at 20:21, Pallipadi, Venkatesh wrote:
> > > 
> > > > And with the kind of power savings that comes with these frequency
> > > > changes, this behaviour 
> > > > results in  longer battery life. However, as yet I do not have any
> > > > numbers to quantify this gain, 
> > > > mainly because I do not have any setup where I can measure actual power.
> > > >  
> > > 
> > > some time ago I did this by using the ACPI method of asking the battery
> > > what the current use is at this point in time; it's of course not as
> > > exact as a full measurement setup but it's a nice poor mans power watch
> > > too ....
> > Unfortunately, there is a number of ACPI-enabled BIOSes which report wrong
> > battery rate when EST is in action -- they still continue to report a rate
> > which corresponds to highest CPU frequency despite the fact that actual
> > frequency might be the lowest one.
> 
> ok I admit to cheating and not actually using ACPI but talking
> to the battery directly based on reverse engineered info (partially based
> on the AML, mostly on "if I do this what value changes" ;)

Most modern embedded chips 'cache' results.  Better to go directly
to the smbus for those one, and talk to the smart battery slave.

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: [PATCHSET] 0/3 Dynamic cpufreq governor and updates to ACPI P-state driver

[Arjan van de Ven]

On Thu, Oct 23, 2003 at 11:24:01AM +0300, Alexander Bokovoy wrote:
> On Thu, Oct 23, 2003 at 10:19:44AM +0200, Arjan van de Ven wrote:
> > On Wed, 2003-10-22 at 20:21, Pallipadi, Venkatesh wrote:
> > 
> > > And with the kind of power savings that comes with these frequency
> > > changes, this behaviour 
> > > results in  longer battery life. However, as yet I do not have any
> > > numbers to quantify this gain, 
> > > mainly because I do not have any setup where I can measure actual power.
> > >  
> > 
> > some time ago I did this by using the ACPI method of asking the battery
> > what the current use is at this point in time; it's of course not as
> > exact as a full measurement setup but it's a nice poor mans power watch
> > too ....
> Unfortunately, there is a number of ACPI-enabled BIOSes which report wrong
> battery rate when EST is in action -- they still continue to report a rate
> which corresponds to highest CPU frequency despite the fact that actual
> frequency might be the lowest one.

ok I admit to cheating and not actually using ACPI but talking
to the battery directly based on reverse engineered info (partially based
on the AML, mostly on "if I do this what value changes" ;)

Re: [PATCHSET] 0/3 Dynamic cpufreq governor and updates to ACPI P-state driver

[Alexander Bokovoy]

On Thu, Oct 23, 2003 at 10:19:44AM +0200, Arjan van de Ven wrote:
> On Wed, 2003-10-22 at 20:21, Pallipadi, Venkatesh wrote:
> 
> > And with the kind of power savings that comes with these frequency
> > changes, this behaviour 
> > results in  longer battery life. However, as yet I do not have any
> > numbers to quantify this gain, 
> > mainly because I do not have any setup where I can measure actual power.
> >  
> 
> some time ago I did this by using the ACPI method of asking the battery
> what the current use is at this point in time; it's of course not as
> exact as a full measurement setup but it's a nice poor mans power watch
> too ....
Unfortunately, there is a number of ACPI-enabled BIOSes which report wrong
battery rate when EST is in action -- they still continue to report a rate
which corresponds to highest CPU frequency despite the fact that actual
frequency might be the lowest one.

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

RE: [PATCHSET] 0/3 Dynamic cpufreq governor and updates to ACPI P-state driver

[Arjan van de Ven]

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

On Wed, 2003-10-22 at 20:21, Pallipadi, Venkatesh wrote:

> And with the kind of power savings that comes with these frequency
> changes, this behaviour 
> results in  longer battery life. However, as yet I do not have any
> numbers to quantify this gain, 
> mainly because I do not have any setup where I can measure actual power.
>  

some time ago I did this by using the ACPI method of asking the battery
what the current use is at this point in time; it's of course not as
exact as a full measurement setup but it's a nice poor mans power watch
too ....

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

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

RE: [PATCHSET] 0/3 Dynamic cpufreq governor and updates to ACPI P-state driver

[Pallipadi, Venkatesh]

 
Hi,
 
I do not have any performance numbers taken from actual probes. 
We have seen in our testing that the the frequency does change based on
the cpu usage.
For example, on a Centrino system, 
- frequency will be lowest when system is idle 
- frequency will be somewhere in the mid-range when you run single app
like mp3/mpeg player
- frequency will be maximum when you run multiple apps 
And with the kind of power savings that comes with these frequency
changes, this behaviour 
results in  longer battery life. However, as yet I do not have any
numbers to quantify this gain, 
mainly because I do not have any setup where I can measure actual power.
 
Thanks,
-Venkatesh  
 

	-----Original Message-----
	From: Mukesh Rajan [mailto:megabyte1024@hotmail.com] 
	Sent: Tuesday, October 21, 2003 4:18 PM
	To: Pallipadi, Venkatesh
	Cc: cpufreq@www.linux.org.uk; linux-kernel@vger.kernel.org;
linux-acpilinux-acpi@intel.com
	Subject: [PATCHSET] 0/3 Dynamic cpufreq governor and updates to
ACPI P-state driver
	
	
	Hii,

	I was wondering if you had any numbers (physical measurements)
proving the same. Over an year ago, I had implemented the same idea on a
Compaq IPAQ (Strong ARM based running ARM Linux). I initially had to fix
the CPU freq code which was broken to get everything working right. But
after all the trouble, with actual probes (NI-DAQ board doing voltage
sampling et al) I measured very little savings in power at all. I
attributed those observations to questionable load average calculations
and very small power savings margin and simply moved on.

	~ Mukesh 

	(Please cc: as I am not in list)

	Hi,

	Most of the latest CPUs (laptop CPUs in particular) have feature


	which enable very low latency P-state transitions 

	(like Enhanced Speedstep Technology-EST). Using this feature, 

	we can have a lightweight in kernel cpufreq governor, 

	to vary CPU frequency depending on the CPU usage. The 

	advantage being low power consumption and also cooler laptops.

	Another related change is enhancing the current ACPI P-state 

	driver to handle:

	EST (and MSR based P-state transitions), make the driver SMP 

	aware and introduce HT coordination in the driver (HT siblings 

	share the same CPU frequency).

	The patches that follow this mail addresses the above issues. 

	They are against 2.6-test7 kernel. Many thanks to Dominik for 

	his comments and suggestions.

	The patches will work on all laptops with EST technology 

	(Centrino) and also on any other system that supports low 

	latency frequency change. 

	Reviews/testing of patches are most welcome.

	Thanks,

	-Venkatesh


  _____  

	Surf and talk on the phone at the same time with broadband
Internet access. Get high-speed for as low as $29.95/month.* 
	<http://g.msn.com/8HMAENUS/2731??PS=> *Depending on the local
service providers in your area. 

RE: [PATCHSET] 0/3 Dynamic cpufreq governor and updates to ACPI P-state driver

[Pallipadi, Venkatesh]

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org 
> [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of 
> Alexander Bokovoy
> Sent: Tuesday, October 21, 2003 2:11 PM
> To: M?ns Rullg?rd
> Cc: cpufreq@www.linux.org.uk; linux-kernel@vger.kernel.org
> Subject: Re: [PATCHSET] 0/3 Dynamic cpufreq governor and 
> updates to ACPI P-state driver
> 
> 
> On Tue, Oct 21, 2003 at 10:39:16PM +0200, M?ns Rullg?rd wrote:
> > Alexander Bokovoy <ab@altlinux.org> writes:
> > 
> > >> > Most of the latest CPUs (laptop CPUs in particular) 
> have feature 
> > >> > which enable very low latency P-state transitions 
> > >> > (like Enhanced Speedstep Technology-EST). Using this feature, 
> > >> > we can have a lightweight in kernel cpufreq governor, 
> > >> > to vary CPU frequency depending on the CPU usage. The 
> > >> > advantage being low power consumption and also cooler laptops.
> > >> 
> > >> So, I took this thing for a spin, but it didn't work at 
> all.  I loaded
> > >> the module, and did "echo demandbased > 
> /sys/.../scaling_governor".
> > >> This echo never returned, and the keyboard locked up.  
> After a little
> > >> while, the fan started running at full speed.  I managed 
> to cut and
> > >> paste into an xterm and start top, which showed nothing 
> unusual.  I
> > >> could shut down and reboot normally.
> > > I applied these patches to stock 2.6.0-test8 and selected 
> 'demandbased' as
> > > default governor. In result, everything worked from the 
> very beginning, my
> > > Centrino-based system went to 600MHz and was upping when 
> load was going
> > > higher during compilation or disk access but went down 
> when load was
> > > lowering. So it works well for me.
> > 
> > What's your /proc/cpuinfo?  Mine says
> > 
> > processor	: 0
> > vendor_id	: GenuineIntel
> > cpu family	: 15
> > model		: 2
> > model name	: Mobile Intel(R) Pentium(R) 4 - M CPU 1.80GHz


AFAIK, Pentium 4 M does not support EST (Frequency transitions with low
latency). 
But that doesn't explain why it is hanging though. Which speedstep
driver are you using?
P4-clockmod? Or acpi? Can you send the complete dmesg.


Thanks,
-Venkatesh

RE: [PATCHSET] 0/3 Dynamic cpufreq governor and updates to ACPI P-state driver

[Pallipadi, Venkatesh]

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org 
> [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of 
> Alexander Bokovoy
> Sent: Tuesday, October 21, 2003 2:11 PM
> To: M?ns Rullg?rd
> Cc: cpufreq@www.linux.org.uk; linux-kernel@vger.kernel.org
> Subject: Re: [PATCHSET] 0/3 Dynamic cpufreq governor and 
> updates to ACPI P-state driver
> 
> 
> On Tue, Oct 21, 2003 at 10:39:16PM +0200, M?ns Rullg?rd wrote:
> > Alexander Bokovoy <ab@altlinux.org> writes:
> > 
> > >> > Most of the latest CPUs (laptop CPUs in particular) 
> have feature 
> > >> > which enable very low latency P-state transitions 
> > >> > (like Enhanced Speedstep Technology-EST). Using this feature, 
> > >> > we can have a lightweight in kernel cpufreq governor, 
> > >> > to vary CPU frequency depending on the CPU usage. The 
> > >> > advantage being low power consumption and also cooler laptops.
> > >> 
> > >> So, I took this thing for a spin, but it didn't work at 
> all.  I loaded
> > >> the module, and did "echo demandbased > 
> /sys/.../scaling_governor".
> > >> This echo never returned, and the keyboard locked up.  
> After a little
> > >> while, the fan started running at full speed.  I managed 
> to cut and
> > >> paste into an xterm and start top, which showed nothing 
> unusual.  I
> > >> could shut down and reboot normally.
> > > I applied these patches to stock 2.6.0-test8 and selected 
> 'demandbased' as
> > > default governor. In result, everything worked from the 
> very beginning, my
> > > Centrino-based system went to 600MHz and was upping when 
> load was going
> > > higher during compilation or disk access but went down 
> when load was
> > > lowering. So it works well for me.
> > 
> > What's your /proc/cpuinfo?  Mine says
> > 
> > processor	: 0
> > vendor_id	: GenuineIntel
> > cpu family	: 15
> > model		: 2
> > model name	: Mobile Intel(R) Pentium(R) 4 - M CPU 1.80GHz


AFAIK, Pentium 4 M does not support EST (Frequency transitions with low
latency). 
But that doesn't explain why it is hanging though. Which speedstep
driver are you using?
P4-clockmod? Or acpi? Can you send the complete dmesg.


Thanks,
-Venkatesh

RE: [PATCHSET] 0/3 Dynamic cpufreq governor and updates to ACPI P-state driver

[Pallipadi, Venkatesh]

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org 
> [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Måns Rullgård
> 
> So, how does this work?  I'd like to be able to set minimum and
> maximum clock frequencies to allow, and CPU utilization thresholds at
> which to switch frequencies.  Is that possible, or is it work yet to
> be done?  Adjustable polling interval would also be nice.
> 

Yes. You can set the maximum and minimum allowed frequencies using 
the standard cpufreq interface. Something like:
echo 800000 >  /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

However, other interfaces to tune this particular governor is not 
there yet. Other tunables that will be exported to user in future are 
Polling interval and CPU utilization thresholds.

> > The patches will work on all laptops with EST technology 
> > (Centrino) and also on any other system that supports low 
> > latency frequency change. 
> 
> Does Pentium 4 M work?

AFAIK, P4M does not support EST. You can double check with 
/proc/cpuinfo and look out for EST flag.


Thanks,
-Venkatesh

RE: [PATCHSET] 0/3 Dynamic cpufreq governor and updates to ACPI P-state driver

[Pallipadi, Venkatesh]

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org 
> [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Måns Rullgård
> 
> So, how does this work?  I'd like to be able to set minimum and
> maximum clock frequencies to allow, and CPU utilization thresholds at
> which to switch frequencies.  Is that possible, or is it work yet to
> be done?  Adjustable polling interval would also be nice.
> 

Yes. You can set the maximum and minimum allowed frequencies using 
the standard cpufreq interface. Something like:
echo 800000 >  /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

However, other interfaces to tune this particular governor is not 
there yet. Other tunables that will be exported to user in future are 
Polling interval and CPU utilization thresholds.

> > The patches will work on all laptops with EST technology 
> > (Centrino) and also on any other system that supports low 
> > latency frequency change. 
> 
> Does Pentium 4 M work?

AFAIK, P4M does not support EST. You can double check with 
/proc/cpuinfo and look out for EST flag.


Thanks,
-Venkatesh