Software Archive
Read-only legacy content
The Intel sign-in experience has changed to support enhanced security controls. If you sign in, click here for more information.
17065 Discussions

Q&A: Enhanced Intel SpeedStep Technology and Demand-Based Switching on Linux*


This is a question received by Intel Software Network Support, along with a response supplied by the author of the article being discussed:

Q. I read Venkatesh Pallipadi's article Enhanced Intel SpeedStep Technology and Demand-Based Switching on Linux*. How do I set this technology in theBIOS?

A. The author responds:

First you need to make sure your processor supports Enhanced Intel SpeedStep Technology. You can do that by looking at the'cat /proc/cpuinfo' output and looking for "est" in flags.

Then you need to make sure your BIOS supports EIST. Make sure you have the latest BIOS for your platform. Then check whether thereis an option in BIOS that says "EIST" or "Enhanced SpeedStep" or something similar to that, and enable it in theBIOS. Some BIOSes have explicit options, and some other BIOSes enable the feature by default.

With that, you should see EIST working with anyof the latest Linux distributions.

If you have aprocessor withthe Enhanced Speedstep feature and SpeedStepTechnology is stillnot working in Linux, please open a bug entry in http// giving details of the issue, under ACPI category in Bugzilla. One of the engineers from our Linux team will help on closing the issue.


Lexi S.

IntelSoftware NetworkSupport

Contact us

0 Kudos
6 Replies

Another set of developer questions about this article and the response from the author:

Q. From a human-interface point of view, it would be very nice if the operating system could adjust the processor speed about 10 times per second. (Linux currently does it once per second, with the default values of the ondemand governor.) The question is, 1) How long does it take to change the processor's p-state? 2) During the transition, for how long is the processor sleeping (assuming it needs to shut down during the transition)? In other words, what would be the negative impact of switching p-state more often than once per second? Could one switch 10x per second without much impact on performance? How about 100x per second?

A. Linux* can switch P-states in various ways.
-ondemand governor: (`cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor` should show ondemand). That governor changes the CPU frequency very rapidly 10 times or more per second, depending on your CPU P-state transition latency and kernel HZ configuration, etc.

-userspace governor: In case you are running user level governor and one of the userlevel freq monitoring daemons (cpuspeed), then you will be doing monitoring at second granularity, as the overhead of such monitoring from userspace is high and doing it more frequently than a second is not practical.

Our suggested way to do P-state transitions on Intel processor-based platforms is to use 'ondemand governor'. Most of the recent Linux distributions use that by default. However, if you are using older Linux distributions, you will have to change your init script to switch to ondemand governor at boot time.

Q. Thank you for your answer, but I was actually asking a different question. Not about the Linux kernel, but about the hardware. It turns out that the ondemand governor in the 2.6.20 linux kernel actually only
switches speed twice per second. I was looking for information on the hardware to see if it was practical to switch speed more often than that. I am looking at the code for the ondemand governor and preparing to modify it to respond more rapidly if the hardware allows. If one tried changed the p-state of a Intel processor (e.g. a Pentium 4) say 100 times a second, what would happen? How often can you change the p-state? How long, after you write the bits to the CPU's register, does it take for the clock frequency and voltages to actually change?

A. The latency to switch P-state depe nds on the processor. You can look at the latency value on your particular processor by

#cat /proc/acpi/processor/CPU*/performance
## Note this may need some particular kernel configuration
Typically this value is 10uS or 100uS. Ondemand, by default,does the monitoring based on this latency. Default sampling interval of ondemand is 1000 times this latency. So, if you have a CPU with latency 100uS, ondemand is already polling at 100 mS (10 times per sec). You may see freq changing lesser number of times than that. But, that will be because thats when CPU load actually changed and not because ondemand is polling once per second. On all Intel systems I have seen ondemand samples atleast 9 times per second.
You can check ondemand sampling value and increase/decrease it by looking at thetunables in
/sys/devices/system/cpu/cpu*/cpufreq/ondemand/ directory.


Lexi S.

IntelSoftware NetworkSupport

Contact us


Q. When the EIST function in BIOS is activated, I can see the change of CPU frequency in computer properties by setting 'Power Schemes' as 'always on' or 'minimal power management' on Windows XP SP2.

My question is: during the sys idle time, how can I detect the change of CPU frequency and voltage when EIST is on? I can only see the CPU static information by cat /proc/cpuinfo. My CPU is Intel Woodcrest 3.00GHz, OS is RHEL4.

A. Yes. On Red Hat EL4, /proc/cpuinfo only gives the max CPU frequency information. You can get the current frequency the CPU is running at by looking at /sys/devices/system/cpu/cpuX/cpufreq/cpuinfo_cur_freq.
for CPU 0 frequency you can do
#cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq

Q. I followed your suggestion to check CPU info under this path with
RHEL4: /sys/devices/system/cpu/cpu0

But I can't find a directory named cpufreq. Isyour advice just for Notebook platform, not for Server platform?If I am right, can you tell ushow to test the CPU's current speed under RHEL4 or SuSE 10 ?

If I am wrong, can you give me a suggestion on how to test the CPU'scurrent speed under Linux?

I wondered whether this could be a BIOS problem, but I can check EIST function under Windows XP SP2 with the same BIOS.

Is this caused bynot installingsome driverfor Intel EIST?

A. Our engineers told us the suggestion is valid for all platforms as long as you have the right driver loaded. The lack of directory suggests that this driver isn't loaded, or is too old in the version of RHEL4 you are using. Without this driver, you will only run at maximum frequency (it is the same driver that controls the hardware and reports the information).

Q. I was trying to install RHEL5 to check this problem. I am using the following command to load thedriver under RHEL5:

#: modprobe p4-clockmod

But it still fails, and reports the following info:

FATAL:Error inserting


No such device.

Would you please tell me which driver you use and with which command? The more detailed, thebetter.Iwonder ifmaybe some ACPI module didn't load normally.

A. You should not use p4-clockmod; it's not saving you any power. You should be using acpi_cpufreq or the Intel Centrino one which is built into the kernel (so no separate driver). If those don't work, you probably have too old a kernel for your machine, and you should contact the support group of your OS vendor about how to get an update to that.


Q. How will this impact the operating systems ability to report CPU utilization?

A. The existing tools on Linux, like top, vmstat etc, are unaware of CPU frequency changes and will not take frequency into account while reporting the idle and busy times. However, there are new set of interfaces in /sys/devices/system/cpu/cpuX/cpufreq/stats/* which gives information about how much time each CPU spent in different frequencies, etc, which can be used along with top to get to actual CPU utilization with varying frequencies.

Windows does not take frequency into account when reporting CPU utilization. Both the utilization and frequency of each core can be monitored using counters in the Processor and Processor Performance objects in the built-in Windows Performance Monitoring (PerfMon) tool.


Gina B.
Intel Software Network Support

Intel is a registered trademark of Intel Corporation or its subsidiaries in the United States and other countries.

*Other names and brands may be claimed as the property of others.


Q. I have followed the article to enable dvfs on a dual processor (Xeon 5160) machine running fc6. I have some question on some data observed.

1: The available frequency setting is only 3000MHz and 2000MHz. Is that normal? The datasheet shows a lot of voltage/frequency points. The same thing is also in the article, only two available frequency points.

2. According to the Xeon 5100 series datasheet, the two cores should share one Vcc, which means two cores on same processor should have the same frequency, but the test result shows I can set core0 to 2GHz while the other three cores still run at 3GHz. Am I understanding the datasheet wrong or anything else wrong?

A. The author responded:

1. Yes. The range looks reasonable. Platform BIOSes can expose more steps within this range (like 2.3 and 2.6 GHz). But in this case itlooks like theBIOS is exposing only 2 P-states, whichis not a bug as such, as it depends on platform design. You may want to check whether you have the latest BIOS, however.

2. Yes. 2 cores in the same socket share same VCC and hence run at same voltage freq. Cores from different sockets can run at different frequencies. You mentioned that you were able to set one core to 2 GHz while others are at 3 GHz. Did you check the frequency as reported by Linux (or any other OS you are using)? The OS can see different freq as it typically reports "last freq set" instead of "current freq". In this case one core may set its freq to 2 GHz, but it will be running faster until the other core also requests lower freq. Hardware picks the max freq requested among all cores in the socket and uses that for common freq.


Lexi S.

IntelSoftware NetworkSupport

Contact us


Q. Is there any complete information available for the frequency and voltage transitions tables for each CPU? Are these in some way able to be determined by software, or are we always at the mercy of BIOS/ACPI bugs? Does Intel publish a document with all the necessary information to make EIST work 100% on a non-Linux, non-Windows, software system?

A. Software that wants to control performance states of the processor should conform to the ACPI 3.0 specification. That software should parse the ACPI tables looking for the _PDC tables constructed by BIOS. Developers should focus on chapter 8 of the ACPI 3.0 specification.


Lexi S.

IntelSoftware NetworkSupport

Contact us


Is there a way under Linux to know if speedstep is enabled? (I know /proc/cpuinfo can give processor flags, but not if the option is enabled on the BIOS, but only if the processor supports it).

Same for TurboBoost.