Implementing processor power management for Windows 7

Information on this page applies to Windows 7 and ealier versions of the Windows operating system. For information about processor power management on Windows 10, see Configure processor power management options.

Windows 7 includes expanded support for the processor objects that are defined in the ACPI 2.0 and ACPI 3.0 specifications. Several of the processor objects are required for Windows 7 to support processor performance states, whereas other processor objects are optional and can be leveraged at the discretion of the system firmware engineer.

This information applies to the following operating systems:

• Windows Server 2008 R2
• Windows 7

The following table lists the ACPI processor objects and indicates which of these objects are supported by the various versions of Windows.

Windows ACPI processor object support

Legend:

• = Supported

X = Not supported

Operating system validation of ACPI processor objects

To increase platform reliability and to help OEMs and firmware developers discover and resolve problems, Windows performs validation checks on the ACPI processor objects that are defined in the system firmware during processor driver initialization. If errors, incorrect or ambiguous information, or other problems are detected, Windows disables the relevant PPM control. In this situation, the kernel power manager logs an error in the system event log that describes which processor control (performance states, idle states, or throttle states) were disabled.

Additionally, the results of this validation are made available through the PowerCfg utility when the /ENERGY parameter is specified. For more information about how to use the PowerCfg utility for energy efficiency analysis, see Using PowerCfg to Evaluate System Energy Efficiency.

Declaring processors

For each processor in the system, the ACPI namespace should declare a named processor object by using the Processor operator. Processor objects may appear anywhere under the \_SB scope or may appear under the \_PR scope to maintain compatibility with ACPI 1.0 operating systems. Processor objects must be in the \_SB or \_PR scope, but not in both.

The processor’s object list may optionally include any of the ACPI processor objects that are listed in the preceding table. The processor objects that are required to support PPM in Windows are described in the remainder of this topic.

Implementing BIOS support for processor performance states

This section discusses the ACPI processor objects that are required to support ACPI processor performance states (P states). Systems that do not support processor performance states should not include these ACPI objects in the ACPI namespace.

Required performance state ACPI objects

Processor P states must be declared in the BIOS by using the ACPI 2.0 performance state objects in the processor’s object list.

The following ACPI objects are required to support processor performance states:

• _PSS
• _PCT
• _PPC

Optional performance state ACPI objects

The following ACPI objects are optional for Windows 7 and Windows Server 2008 R2 to support processor performance states:

• Notify(CPU, 0x08)
• _OSC, _PDC
• _PSD
• XPSS

Note  For more information about the Microsoft-defined XPSS method and the generic processor driver interface, see Generic processor driver and Extended PSS ACPI Method Specification.

Describing processor control dependencies

System firmware may optionally describe platform control dependencies for processor performance, throttle, or idle states by using the dependency objects that were introduced for this purpose in ACPI 3.0. If present, each dependency object must describe no more than one coordination domain. If the platform supports processor performance states and describes a domain dependency by using _PSD, the kernel power manager uses the P state domain dependency relationship information to control processor linear throttle states.

Artificial processor performance state domains

When Windows Vista and Windows Server 2008 were developed, several dual-core and dual-logical processor designs were prevalent in the marketplace. These CPUs typically provide one set of performance state controls that are shared across both cores or both logical processors, which implies that a control dependency exists. However, the system firmware for systems that have these CPUs targets earlier operating systems or otherwise predates the release of Windows Vista and therefore generally does not provide the ACPI 3.0 dependency objects. To support these popular processors without first requiring a platform BIOS update, Windows 7 creates an “artificial” processor performance state dependency domain for the operating system to use. Windows synthesizes a dependency domain for all logical processors in the same physical package. This is the default behavior for Windows 7, and therefore the _PSD object is not required to be present in the ACPI namespace to realize multiprocessor performance states on systems that are equipped with these dual-core processors.

For future systems that might provide two processor cores that share the same physical package but that have independent PPM controls, the default behavior of creating an artificial control dependency domain can be overridden in the following two ways:

• Include a _PSD object in the ACPI namespace that describes a separate dependency domain number for each logical processor or for each processor core.

• Create a DWORD value that is named PerfEnablePackageIdle under the following registry key and set its value to 1:

  HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Throttle
  

Implementing BIOS support for processor idle states

This section discusses the ACPI processor objects that are required to support ACPI processor idle states (C states). Systems that do not support processor idle states should not include these ACPI objects in the ACPI namespace.

Processor C states can be declared in the BIOS by using either of the following ACPI processor idle state control interfaces:

• The ACPI 2.0 _CST object in the processor’s object list.
• The legacy ACPI 1.0 interface that uses the Processor Register Block (P_BLK) P_LVL2 and P_LVL3 registers and FADT P_LVLx_LAT values.

C state enumeration

The processor driver first looks for support for ACPI 2.0 C states in the system firmware, as indicated by the presence of the _CST and _CSD objects in the ACPI namespace. If the system does not support ACPI 2.0 C states, the driver looks for support for ACPI 1.0 C states.

ACPI 2.0 C state initialization

During initialization, the processor driver looks for and evaluates the _CST and _CSD ACPI objects. If the processor driver finds these objects, it performs validation checks to ensure that these objects are correctly populated and compatible with Windows C state support. The following validation checks are performed:

• _CSD object validation

  The _CSD object must report that the system supports hardware coordination of C states (CoordType = 0xFE, HW_ALL). If any other value is reported for CoordType, all C states other than C1 are disabled on the system.

• _CST object validation

  • The C-states that are listed in the _CST object must be ordered with increasing values for:

    C state type (C1, C2, and so on)

    Latency

    Power

  • All C state control register addresses must be located in I/O space.

  • All entries must have valid addresses for the required ACPI BIOS interfaces:

    • The C2 state must have a valid address for the PM1a control block.

    • The C3 state must have valid addresses for the:

      PM2 control block

      PM1a control block

      PM1a event block

ACPI 1.0 C state initialization

If support for ACPI 2.0 C states is not present in the system firmware, the processor driver attempts to initialize ACPI 1.0 C states. The following validation checks are performed:

• C1 validation

  C1 is enabled on all systems by default.

• C2 validation

  • The P_LVL2_LAT value that is reported in the FADT must be below 100 µs.
  • There must be a valid address for the PM1a control block.
  • There must be a valid P_BLK address.
  • The system must be a uniprocessor system. C2 is not supported on multiprocessor systems by default, unless the processor driver explicitly enables this based on known capabilities of the system.

• C3 validation

  • The P_LVL3_LAT value that is reported in the FADT must be below 1000 µs.
  • There must be a valid address for the PM2 control block.
  • There must be a valid address for the PM1a control block.
  • There must be a valid address for the PM1a event block.
  • There must be a valid P_BLK address.
  • The system must be a uniprocessor system. C3 is not supported on multiprocessor systems by default, unless the processor driver explicitly enables this based on known capabilities of the system.

Implementing BIOS support for processor clock throttling

This section discusses the ACPI processor objects that are required to support ACPI processor linear stop clock throttle states (T states). Systems that do not support processor T states should not include these ACPI objects in the ACPI namespace.

Processor T states can be declared in the BIOS by using either of the following ACPI processor throttling control interfaces:

• The ACPI 2.0 and 3.0 _PTC, _TSS, and _TPC objects in the processor’s object list.
• The legacy ACPI 1.0 interface that uses the Processor Register Block (P_BLK) P_CNT register.

T state enumeration

The processor driver first looks for support for ACPI 3.0 T states in the system firmware, as indicated by the presence of the _PTC, _TSS, and _TPC objects in the ACPI namespace. If the system does not support ACPI 3.0 T states, the driver looks for support for ACPI 1.0 T states.

ACPI 3.0 T state initialization

During initialization, the processor driver looks for and evaluates the _PTC, _TSS, and _TSD ACPI objects. If the processor driver finds these objects, it performs validation checks to ensure that these objects are correctly populated and compatible with Windows T state support. The following validation checks are performed:

• _PTC object validation

  The _PTC must use either I/O mapped or FFH controls.

• _TSS object validation

  • The _TSS entries must be ordered in descending order of T-state and power.
  • The first _TSS entry must be 100 percent (no throttle).

• _TSD object validation

  • The _TSD object, if present, must describe only one coordination domain.
  • The _TSD object must contain no more than five fields.
  • The _TSD coordination type must be one of the three coordination types that are defined by ACPI 3.0.
  • The _TSD domain must contain at least one member, and the member count must not be greater than the total number of processors that are declared in the ACPI namespace.

ACPI 1.0 T state initialization

If support for ACPI 3.0 T states is not present in the system firmware, the processor driver attempts to initialize ACPI 1.0 T states. The following validation checks are performed:

• T-states on multiprocessor systems

  The system must be a uniprocessor system. ACPI 1.0 T-states are not supported on multiprocessor systems, unless the processor driver for the system’s specific processor explicitly supports and enables the multiprocessor T state capability that is based on known capabilities of the system.

• Processor Register Block address

  The Processor Register Block (P_BLK) address must be located in I/O space.

• Throttling values

  • The FADT DUTY_WIDTH value must be >0 and ≤4.
  • The sum of the FADT DUTY_OFFSET and DUTY_WIDTH values must be ≤32.

Related topics

Processor Power Management in Windows 7 and Windows Server 2008 R2

Send comments about this topic to Microsoft