Re: Why do CPUs run hotter...?

mc wrote:
Can anyone confirm that Windows' idle loop uses WAIT ops?
It does. Since Win98, anyway. Win95 was iffy.

If so, then the CPU really is idle for milliseconds at a time when it's running the idle
loop. Thanks for this interesting clue.
Certainly.

OK, that explains a great deal. Many thanks. Is it WAIT or HALT? It's been a while since I did '86 assembly language, but as I recall, WAIT waits for an i/o port condition and HALT waits for an interrupt.

krw's comments have good information. Here is a bit more detail, and some places you can look for more information:

The opcode in x86/ia32 is called "HLT" (no 'A'). As krw points out, this opcode has been in x86 for a long time (actually, since the 8086). Around the Pentium era, chip makers started to make a real effort to make the chip go into a lower power state when this instruction is executed. There are lots of ways to achieve this. Early chips would only stop various clock trees (with very respectable power decreases). Later generations added more and more platform facilities to help lower the power. As mentioned elsewhere in the thread, this includes voltage and frequency scaling, as well as techniques to reduce leakage.

A good description of what "HLT" should do is in the ACPI spec. The ACPI spec is freely downloadable at acpi.info. The HLT instruction corresponds to the C1 CPU state in ACPI terms. The main gist of the definition is that the latency for exit has to be small enough to be negligible, and cache coherency must be maintained while in the state. An interrupt should transition the CPU to C0 (full on state), but masters to memory do not (they just must be snooped properly).

The C2 CPU state is an even lower power state. The requirements are similar to the C1 state, but the biggest difference is that that wake time can be up to 100us. Cache coherency must still be maintained. On an x86, this state is entered by reading an I/O location (this I/O port could be implemented in several different places). The exact location to read is reported to the OS through the ACPI tables.

C3 is meant to be even lower power, and can have a wake time of up to 1ms. The difference between this state and C2 is that cache coherency does not have to be automatically be maintained; bus masters are actually "held off" in this state, and when one is detected, the system must sequence to a higher power state to allow the master and proper snooping to occur. The ACPI spec also describes a facility to flush the cache before entering this state (so masters don't have to be held off), but this isn't really a very optimal implementation.

Windows XP will use 'HLT' in its idle loop by default on an ACPI compliant system. If C2 is available (the OS knows this from the ACPI tables), XP will use it instead of C1. XP has some sort of prediction algorithm to know which of C2 or C3 to use, based on the latencies for each (also communicated to XP through the ACPI tables.)

A further level of performance/power management is with CPU "P-States". These are states that can be entered that lower the relative performance of the processor, while still running code. These can be implemented with clock throttling or with frequency scaling (or maybe some other way). The important difference between P and C states is that P states are used when code still needs to be running, but it is ok to run it at a reduced performance level. C states are used in "idle loops", where no code is running, and the system is waiting for an interrupt.

As a tangent to the original question, "WAIT" on an x86 is used to wait for an x87 FPU result. It doesn't really have anything to do with idle loops.

A bit more tangential: the P4 added a "PAUSE" opcode, which waits for "a while" before proceeding. The time waited is not specified in any databook. This instruction was added to be used in spin-lock loops, where a (logical) processor is spinning polling on a memory location. The PAUSE opcode is a hint to the processor that it is in a spin-wait loop, and it avoids a particular memory order violation that reduces performance. This was really added to help Intel's HT technology. Details are sort of scant, but you can find some information if you google for it. The relevant point is that a lower power state can be entered on the PAUSE instruction. It looks like it has been added to at least some version of the Win32 API:

http://msdn.microsoft.com/msdnmag/issues/05/10/ConcurrentAffairs/default.aspx?side=true

A good place to look for more information about "HLT" in in the Intel manuals:

http://developer.intel.com/design/Pentium4/manuals/253665.htm

For more about C2, C3, and the fancy scaling stuff, you'll have to look at southbridge datasheets (ICHx for Intel stuff)
.

Relevant Pages

  • Re: [PATCH] add i386 idle notifier (take 3)
    ... Here is the latest version of the idle notifier for i386. ... This patch is against 2.6.20-rc1. ... add a notifier mechanism to the low level idle loop. ...
    (Linux-Kernel)
  • Re: [PATCH] add i386 idle notifier (take 3)
    ... Here is the latest version of the idle notifier for i386. ... add a notifier mechanism to the low level idle loop. ...
    (Linux-Kernel)
  • Re: Text window not displaying inside loop
    ... // Idle until the screen redraws itself, ... MSG msg; ... functionality to loop every X-seconds then checking the figures again. ... trying to display them fresh on each loop to a text box. ...
    (microsoft.public.vc.mfc)
  • Re: anyone try to slow down celeron m
    ... I mean that the Windows idle loop in all versions of Windows since 98SE is a halt instruction ... ... There used to be "CPU Cooling programs" that modified Windows by replacing the loop with a halt instruction (and the temperature of the CPU dropped sometimes dramatically -- 10 degrees C or more. ... But to the point of the original poster, so is slowing down the processor not necessary to save power/heat WHEN THE COMPUTER IS IDLE. ...
    (comp.sys.laptops)
  • RE: 2.6.28-rc6-mmotm1126 - acpi AE_AM_INFINITE_LOOP errors..
    ... 2.6.28-rc6-mmotm1126 - acpi AE_AM_INFINITE_LOOP errors.. ... You could try making the max loop count larger, ... It went off to somewhere for 28 seconds trying to init the thermal code.. ... Call Trace: ...
    (Linux-Kernel)