The Windows operating system uses power-management hardware to put the computer into a low-power sleep state instead of shutting down completely, so that the system can quickly resume working. The operating system will automatically enter the sleep state when the computer is idle or when the user presses a button to indicate that the current work session is over. To the user, the system appears to be off. While in the sleep state, the computer's processor is not executing code and no work is being accomplished for the user.
However, events in the system from both hardware devices and the real-time clock can be enabled to cause the system to exit the sleep state that is, "wake up" and quickly return to the working state. This notification is optional, and may be ignored by the PEP. If accepted, the PEP is allowed to use the veto reasons between 1 and VetoReasonCount, inclusive, to veto any processor, platform, or coordinated idle state. The OS does not guarantee that the callbacks will not fail due to allocation failures or other issues.
The Windows power management framework PoFx sends this notification at processor initialization to query for information about a specific veto reason. The name should be a human-readable string indicating what condition this veto reason represents. Debugging tools such as WPA and the kernel debugger will display Name when diagnosing why an idle state was not entered. The Windows power management framework PoFx sends this notification after processor initialization but before first idle entry to indicate that the OS is ready to accept calls to ProcessorIdleVeto or PlatformIdleVeto.
The PEP may enumerate any boot-time vetoes in the context of this notification, and the OS guarantees that they will take effect before the first attempt to select a processor, platform, or coordinated idle state. This notification has no associated Data parameter. The Windows power management framework PoFx sends this notification at runtime to inform the PEP of the current core parking mask. Informs the PEP that the OS would like it to select a preferred set of cores to park or steer interrupts away from.
To assist the PEP in providing a consistent response to the OS for a performance check, the OS will supply the interrupt time based timestamp of the performance check evaluation that prompted the notification. All park selection notifications resulting from one performance check evaluation will have the same timestamp. Note that the remaining fields Count, AdditionalUnparkedProcessors, EvaluationType, and Processors may vary for notifications that are sent during the same performance check evaluation, the PEP cannot assume that they will remain the same.
The Windows power management framework PoFx sends this notification at runtime to notify the PEP that the periodic per check evaluation has completed. The Windows power management framework PoFx sends this notification at processor initialization to query the PEP for the dependencies of each coordinated idle state. The ExpectedState field then refers to the index of a processor idle state on the target processor. The ExpectedState field then refers to the index of a coordinated idle state.
Each dependency lists a menu of options the OS is allowed to use to satisfy the dependency. When going idle, the OS will attempt to satisfy the dependency by checking the conditions for each, from highest index to lowest index. If the conditions for a dependency are met, then the OS will consider the dependency met.
If none of the conditions can be met, the dependency is not met and the coordinated idle state may not be entered. The Windows power management framework PoFx sends this notification at processor initialization to query the PEP for information about a specific coordinated or platform idle state. The name should be a human-readable string indicating the name of the coordinated idle state. Coordinated idle states should have unique names, except on multi-cluster systems, where the names of equivalent states on different clusters may be the same.
The Windows power management framework PoFx sends this notification to the PEP at processor initialization to query for the properties of all coordinated idle states. Coordinated idle states may only depend on other coordinated idle states with a lower index. There is not required order between two disjoint coordinated idle states that is, two coordinated idle states that depend on disjoint sets of processors.
The Windows power management framework PoFx sends this notification at processor initialization to query the PEP for information about a specific processor idle state.
This notification is sent to all processors simultaneously after the system has completed all passive level work transitioning the processor to the system power state. Note The PEP must not queue any work from this notification.
The processors will not process work items, DPCs, etc. Direct hardware control over vertical and horizontal sync signals supplement full support for industry-standard VESA hardware and software power management protocols to ensure the widest possible compatibility - including support for multiple monitor setups. Windows NT - The EnergySaver's power management services are available to NT itself and to all users, regardless of rights and privileges, but you must have administrative privileges in order to install the software.
For additional assistance in extending DPMS services to all users, please download and consult the small patch here 16k.
For example, you can restrict the processor to 75 percent of its maximum frequency by using the following commands:. Capping processor performance at a percentage of maximum requires processor support. The CPU utilization-based power management algorithms typically uses a average CPU utilization within a time check window to determine if frequency needs to increase or decrease. As a result, power management will choose a low frequency for this processor.
This issue exists on HWP-based power management as well. The DPCs and threads handling the IO completion or network packets are in the critical path and should not run at low speed. When the DPC count is above certain threshold in the past monitoring window, PPM will enter an IO responsiveness period and raises the frequency floor to a higher level.
The frequency floor will be reset when the DPC count is low enough for some time. The behavior can be tuned by the following parameters. For example, if your server workload is not sensitive to the latency and wants to loose the responsiveness override to favor power, you can increase the Processor responsiveness override enable threshold and Processor responsiveness override enable time, decrease the Processor responsiveness override disable threshold and Processor responsiveness override disable time.
Then the system will be hard to enter responsiveness override state. The default value of Processor responsiveness override performance floor is set as so that the responsiveness override period will run at maximum frequency. You can also decrease the processor performance floor and reduce the Processor responsiveness override energy performance preference ceiling to let HWP to adjust the frequency. The following are the sample commands to set the parameters for current active power plan.
However, this feature increases CPU core energy consumption, so Windows Server configures Turbo technologies based on the power policy that is in use and the specific processor implementation. For Balanced power plans on systems that rely on traditional P-state-based frequency management, Turbo is enabled by default only if the platform supports the EPB register.
To enable or disable the Turbo Boost feature, the Processor Performance Boost Mode parameter must be configured by the administrator or by the default parameter settings for the chosen power plan.
Processor Performance Boost Mode has five allowable values, as shown in Table 5. For P-state-based control, the choices are Disabled, Enabled Turbo is available to the hardware whenever nominal performance is requested , and Efficient Turbo is available only if the EPB register is implemented. You must run the powercfg -setactive command to enable the new settings.
You do not need to reboot the server. Replace "scheme current" in the powercfg -setactive commands previously shown with the desired alias to enable that power plan. For example, to adjust the Boost Mode in the Power Saver plan and make that Power Saver is the current plan, run the following commands:. The speed at which a processor performance state increases or decreases is controlled by multiple parameters. The following four parameters have the most visible impact:.
Processor Performance Increase Threshold defines the utilization value above which a processor's performance state will increase. Larger values slow the rate of increase for the performance state in response to increased activities. Processor Performance Decrease Threshold defines the utilization value below which a processor's performance state will decrease.
Larger values increase the rate of decrease for the performance state during idle periods. Processor Performance Increase Policy and Processor Performance Decrease Policy determine which performance state should be set when a change happens. For example, if your server requires ultra-low latency while still wanting to benefit from low power during idle periods, you could quicken the performance state increase for any increase in load and slow the decrease when load goes down.
The following commands set the increase policy to "Rocket" for a faster state increase, and set the decrease policy to "Single". The increase and decrease thresholds are set to 10 and 8 respectively. Core parking is a feature that was introduced in Windows Server R2. The processor power management PPM engine and the scheduler work together to dynamically adjust the number of cores that are available to run threads.
0コメント