Windows Native Processor Performance Control

Windows Native Processor Performance Control — 1

Windows Platform Design Notes

Designing Hardware for the Microsoft Windows Family of Operating Systems

Abstract: Microsoft® Windows® XP and the Windows Server2003 family include built-in processor performance control to take advantage of microprocessors that utilize performance states to operate the processor more efficiently when it is not fully utilized. This paper outlines the new BIOS implementations needed to expose this capability in Windows. This paper also details the functionality and policies employed by Windows for processor performance control.

The current version of this paper is available on the web at

Version 1.1a — November 12, 2002

Contents

Introduction

Windows Processor Performance Control

The Processor Driver Architecture

Processor Performance Control Policy

Dynamic Throttling Policy Details

Performance State Changes Outside the Scope of Policy

Parameters to P-state policy

Processor Performance State Transition Latency Issues

Parameters to C-State Policy

C-State Control Registry Key

Implementing Processor Performance Control for Windows

Support using ACPI 2.0 Processor Objects

ACPI 2.0 Processor Objects Design Guidelines for Windows

Supporting Systems with Intel SpeedStep and Enhanced SpeedStep Technology

Supporting Intel SpeedStep Technology using ACPI 2.0 Objects

Supporting Enhanced Intel SpeedStep Technology

Supporting the Intel SpeedStep Legacy Applet Interface

Supporting Systems with AMD PowerNow! Technology

Implementing for the K6/2+

Implementing for the K7

Supporting Systems with Transmeta LongRun Technology

"Designed for Windows XP" Logo Program Requirements

Call To Action

References

Appendix A

Processor Driver Capabilities Method (_PDC) Definition

Disclaimer:Microsoft Corporation may have patents or pending patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. The furnishing of this document does not give you any license to the patents, trademarks, copyrights, or other intellectual property rights except as expressly provided in any written license agreement from Microsoft Corporation.

This is a preliminary document and may be changed substantially prior to final public release. This document is provided for informational purposes only and Microsoft makes no warranties, either express or implied, in this document. Information in this document, including URL and other Internet Web site references, is subject to change without notice. The entire risk of the use or the results of the use of this document remains with the user. Unless otherwise noted, the example companies, organizations, products, people and events depicted herein are fictitious and no association with any real company, organization, product, person or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Portions of this document specify software that is still in development. Some of the information in this documentation may be inaccurate or may not be an accurate representation of the functionality of final documentation or software. Microsoft assumes no responsibility for any damages that might occur directly or indirectly from these inaccuracies.

Microsoft does not make any representation or warranty regarding specifications in this document or any product or item developed based on these specifications. This document is provided to you on an AS IS basis. Microsoft disclaims all express and implied warranties, including but not limited to the implied warranties or merchantability, fitness for a particular purpose and freedom from infringement. Without limiting the generality of the foregoing, Microsoft does not make any warranty of any kind that any item developed based on these specifications, or any portion of a specification, will not infringe any copyright, patent, trade secret or other intellectual property right of any person or entity in any country. It is your responsibility to seek licenses for such intellectual property rights where appropriate. Microsoft shall not be liable for any damages of any kind arising out of or in connection with the use of these specifications, including without limitation, any direct, indirect, incidental, consequential (including any lost profits), punitive or special damages, whether or not Microsoft has been advised of such damages. . Some states do not allow the exclusion or limitation of liability or consequential or incidental damages; the above limitation may not apply to you.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Microsoft, Windows, and Windows NT are trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries. Other product and company names mentioned herein may be the trademarks of their respective owners.

Introduction

Historically, processors for mobile PC systems ran at lower voltages than processors for desktop PCs; consequently, processors for mobile PC systems also had to run at slower clock speeds. This was not usually an issue because mobile PCs have relatively slow disk and memory subsystems. Mobile PC processors are usually idle when most business applications are being used.

The situation is different if high bandwidth I/O subsystems are implemented or if the user is doing something that has high CPU utilization and low I/O bandwidth requirements. This can be the case with many games, and also with DVD playback. Many games will try to use all available CPU. The DVD playback case is different because most soft DVD players will only use about 500MHz of the processor capability.

Understanding these limitations in a market environment where “speed” is an important sales factor, CPU manufacturers have introduced processors that employ performance states. These CPUs provide high voltage/high frequency states for use when processor utilization is high, and low voltage/low frequency states to conserve battery life. This technology gives OEMs the ability to design a system that can compete both in the speed and battery life benchmark tests.

Windows XP and the Windows Server2003 family include native support for control of processor performance states. This paper explains the implementation details needed to use Windows native support, and outlines the policies that Windows uses for processor performance control. The paper covers implementation of generic ACPI 2.0 support, and specific details for Intel SpeedStep, Enhanced Intel SpeedStep, AMD PowerNow!, and Transmeta LongRun processor performance control technologies.

Windows Processor Performance Control

The Native support for processor performance control in Windows consists of two components: the kernel power policy manager, and a processor driver. The kernel power manager is responsible for managing processor performance control policy, which is the set of rules used to determine the appropriate performance state to be used at any given time. The kernel power manager’s processor performance control policy algorithms make decisions based on several inputs, including:

Current power policy and processor dynamic throttling algorithm
Heuristics such as processor utilization, current battery level, use of processor idle states, and inrush current events
Thermal conditions and events
Current platform capabilities, as conveyed by system firmware
System standby and resume transitions

Processor performance control is implemented using a processor driver architecture. The kernel power manager calls into the processor driver to invoke changes on the kernel’s behalf. The processor driver does not make decisions about when to change performance states, except as noted later in this paper.

The Processor Driver Architecture

Windows provides support for different manufacturer’s processors by abstracting specific implementation details in a processor driver that provides a unified interface to the kernel power manager. The processor driver architecture allows Windows to take full advantage of individual technologies from different CPU vendors, and allow for support of future advances in processors by providing an easy update path for new functionalities and technologies via development of a new processor driver.

Windows supports processor performance control described by the Processor Objects defined in the Advanced Configuration and Power Interface (ACPI) specification, version 2.0, and legacy interfaces defined by Intel, AMD, and Transmeta. Implementation details for products from each CPU vendor are provided later in this paper.

All processor drivers are based on and statically linked against a common library, proclib.lib, which forms the basis of each driver and represents the majority of the functionality. Routines specific to each processor model reside in the driver for that processor family, and may add to the functionality common to all processor drivers.

Windows provides a generic processor driver, processr.sys, which is capable of supporting processors, whose processor performance control interface is described using the ACPI 2.0 processor performance control objects, where the _PCT object is defined using and I/O address space.

Additional drivers specific to processor families may also be developed. These processor-specific drivers may contain code to support legacy interfaces, or have knowledge about advanced features and performance afforded by a particular vendor’s processor performance control technologies. This includes processor families whose processor performance control interface is implemented using Functional Fixed Hardware, as described in the ACPI 2.0 specification.

Processor Performance Control Policy

In Windows, the processor performance control policy is linked to the Power Scheme setting in the Windows control panel power options applet. No additional UI is required to set the policy.

Windows defines four control policies, known as processor dynamic throttling policies, for processor performance control:

ConstantAlways runs at lowest performance state

AdaptivePerformance state chosen based on CPU demand

DegradeStarts at lowest performance state, then uses linear performance reduction (stop clock throttling) as battery discharges

NoneAlways runs at the highest available performance state

NOTE: The term stop clock throttling refers to linear clock reduction as described by the DUTY_WIDTH and DUTY_OFFSET values in the FADT, and defined in the ACPI 2.0 specification, sections 4.7.3.5.1 and 8.1.1.

The following table shows the relationship between Power Policy Schemes and processor dynamic throttling policies.

Power Scheme / AC Power / DC Power
Home/Office Desk / None / Adaptive
Portable/Laptop / Adaptive / Adaptive
Presentation / Adaptive / Degrade
Always On / None / None
Minimal Power Management / Adaptive / Adaptive
Max Battery / Adaptive / Degrade

Dynamic Throttling Policy Details

The processor dynamic throttling policies used by Windows are explained in more detail below.

NOTE: All policies will always respect the highest available performance state currently available as reported in the _PPC method by system firmware, when using the ACPI 2.0 interface.

None

This policy always runs the processor at the highest performance state currently available. When using this policy, the only reason that Windows will lower the performance of the processor is in response to a thermal event, with the exception of the cases noted later in this paper in the section titled Performance State Changes Outside the Scope of Policy.

Adaptive

This policy tries to match the performance of the processor to current demand. Adaptive will use all available voltage/frequency (performance) states. Adaptive will lower the performance of the processor to the lowest voltage/frequency state available whenever there is not enough demand on the processor to justify the use of a higher state. Adaptive will not utilize linear stop clock throttle states, except in response to thermal events.

Constant

This policy always runs the processor in the lowest available voltage/frequency (performance) state. Constant will not utilize linear stop clock throttle states, except in response to thermal events.

Degrade

The Degrade policy always runs the processor in the lowest available voltage/frequency (performance) state. Additionally, Degrade will utilize linear stop clock throttling under the following conditions:

When the battery remaining capacity drops below a certain threshold (configurable in the registry), AND
The system is not using the C3 idle state effectively; that is, the system is too busy to spend a certain length of time (configurable in the registry) in the C3 state.

The Degrade policy will never throttle below a minimum level, also configurable in the registry. See the following section for details.

PerformanceState Changes Outside the Scope of Policy

There are several instances where either the kernel power policy manager or processor driver will request a performance state transition outside the scope of the processor dynamic throttling policies. These include:

In a thermal event, where the temperature has crossed a passive trip point (_PSV), the kernel thermal throttling code will successively use any available lower voltage/frequency states to cool the system. If the thermal condition persists and all available performance states have been exhausted, the kernel will then use linear stop clock throttling states.
When entering any system sleep state (ACPI Sx state), the processor driver will first save the current performance state, and then set the processor to the lowest voltage/frequency state available prior to entering the system shutdown handler.
When resuming from any system sleep state, the kernel will temporarily set the processor to the highest available performance state to ensure fast resume performance. Once the system has awakened, the performance state saved prior to entering sleep is restored, and the current processor policy then takes effect.
When the OS is starting a device that indicates to the OS that transitioning the device to the working state causes a significant start up in-rush current load, the kernel power policy manager will temporarily transition the processor to the lowest voltage/frequency state available until the device has been started. In-rush current serialization requirements are conveyed to the OS via the presence of the_IRC object under the scope of the device in the ACPI name space, or if the DO_POWER_INRUSH flag is set in the device’s driver device object.

Parameters to P-state policy

Several parameters to Windows processor performance state controls are configurable via registry keys. These keys are provided with the intent that OEMs and system designers may tune the performance of Windows processor power management features to best suit specific platform designs, and allow adjustment to help achieve maximum battery life and realize the best system performance.

NOTE: These parameters are statically adjustable; that is, they are read once during the kernel initialization code. Adjustments made to these values will not take place until the next system reboot.

The following registry keys are found in:

KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Throttle

Registry Key Name / Default Value / Description
PerfTimeDelta / Hardware Transition Latency / This value influences the frequency with which the OS will re-evaluate appropriate performance state in the idle loop.
PerfCriticalTimeDelta / 300000 (300ms) / An application may use so much of the CPU’s time that the OS will never enter the idle loop. In order to make sure that we will increase the performance of the CPU in this situation, the processor power policy manager sets a timer that will interrupt the application. This value influences the time that must pass before the timer will fire.
PerfIncreasePercentModifier / 20 (%) / This value scales the threshold at which the OS increases the performance of the processor.
PerfIncreaseAbsoluteModifier / 1 (%) / This value offsets the threshold at which the OS increases the performance of the processor.
PerfDecreasePercentModifier / 30 (%) / This value scales the threshold at which the OS decreases the performance of the processor.
PerfDecreaseAbsoluteModifier / 1 (%) / This value offsets the threshold at which the OS decreases the performance of the processor.
PerfIncreaseTimeValue / 10000 (10ms) / This value influences the amount of time that may pass before the OS will increase performance. This time is also influenced by the processor’s transition latency.
PerfIncreaseMinimumTime / 150000 (150ms) / This value sets a minimum amount of time that must pass before any increase in performance will be considered.
PerfDecreaseTimeValue / 10000 (10ms) / This value influences the amount of time that may pass before the OS will decrease performance. This time is also influenced by the processor’s transition latency.
PerfDecreaseMinimumTime / 500000 (500ms) / This value sets a minimum amount of time that must pass before any decrease in performance will be considered.
PerfDegradeThrottleMinCapacity / 50 (%) / This value sets a minimum performance level that will be used for any reason other than a thermal condition.
PerfMaxC3Frequency / 50 (%) / This value is the threshold at which the OS will stop using stop-clock throttling and just use idle states; i.e., if the machine is using the Degrade policy and the battery is low, the OS will throttle the CPU, unless the machine is spending at least this amount of its time in the ACPI C3 state. If the machine is spending at least this amount of time in C3, then no throttling will be done, unless there is a thermal condition.

ProcessorPerformanceState Transition Latency Issues

Since the launch of Windows, there have been several problem sightings linked to processor performance state transition latencies. Typically, problems can arise with USB audio playback, video capture or streaming, and soft audio or soft modem implementations. The problems occur due to excessive latency in performance state transitions. Since access to main system memory must be temporarily interrupted during the transition to a new performance state, DMA transfers may suffer from buffer underrun conditions, causing bus master agents to be starved for data. Excessive overhead incurred in legacy SMM transition routines has been identified as contributing to this condition. Microsoft encourages system designers to take full advantage of the high performance transition characteristics afforded by the MSR interface available in many mobile processors, and work with CPU Vendors to reduce performance state transition latencies in system firmware.