Windows® Internals, Sixth Edition, Part 2

The first check is to verify whether this processor has been selected for parking in step 3. If it was selected, the target power state for parked cores, based on policy, is selected. Three possibilities exist:

Lightest The parked processor is targeted to run at 100 percent of its frequency.

Deepest The parked processor is targeted to run at 1 percent of its frequency.

No Preference The parked processor will be treated just like any other processor and continue the regular algorithm.

Assuming that the algorithm does continue, the next step is to compute the busyness of the processor. Since the utility function is equal to the busyness percentage multiplied by the average frequency, this means that the busyness of the processor is its utility divided by its average frequency. This busyness is then compared with the increase and/or decrease thresholds specified by policy, and one of the three possible actions are taken (ideal, step, or rocket, described earlier in Increase/Decrease Actions).

The domain performance handler callback (owned by the vendor-supplied processor driver) is then called with the new target frequencies and with whether throttling was allowed by the policy.

Step 6: Selecting domain state As shown in the previous illustration, this step is also composed of a few substeps. The first, done remotely, is performed by PpmPerfSelectDomainStates, which picks the domain masters and calls PpmPerfSelectDomainState to run on them. This function iterates over all the processors in the domain and picks the one with the highest performance state (the highest desired frequency). It then sets this as the desired frequency for the entire domain.

Now that each domain master has selected its domain state, control returns to PpmPerfSelectDomainStates, which queues a local DPC for all of the domain masters that is implemented by PpmPerfApplyDomainState. This is the second step. This function takes into consideration the valid P states (and T states, if throttling is enabled by policy) and trims any states outside the current processor constraints, which include percentage caps and thermal caps. When it has picked the best target frequency (and consulted with the domain performance handler callback), it queues a DPC to all the processors in each domain to apply the selected performance state to each core.

In this third step, implemented by the PpmPerfApplyProcessorState DPC routine, the domain’s performance handler callback is called to switch states. Finally, PpmScaleIdleStateValues is called. If idle scaling is enabled by policy, this function scales the processor’s C states (idle states) according to the promotion/demotion percentages specified in the policy.

EXPERIMENT: Viewing Current PPM Check Information

The kernel debugger includes an extension, !ppmcheck, which you can use to check whether core parking is enabled and which cores are currently parked, as well as the internal performance checking algorithm state. Here’s a sample output of the extension:lkd> !ppmcheck PpmCheckArmed: TRUE PpmCheckStartDpc: 0x8377aa58 PpmCheckDpc: 0x8377aa78 PpmCheckTimer: 0x8377aa30 PpmCheckMakeupCount: - PpmCheckLastExecutionTime: - PpmCheckTime: 08:40.738.783us (0x50a26d3d) PpmCheckPhase: 9 PpmCheckRegistered: 0x8376b408 {[0000000F]} PpmPerfStatesRegistered: 0x8376b390 {[0000000F]} CoreParkingEnabled: TRUE CoreParkingMask: 0x8376b35c {[0000000A]}