What Does Unparking Cores Mean and What Do They do???

Core parking is one of those things that enthusiasts consistently fail to understand. However, most are too proud to admit as much, and proceed to make up a bunch of mumbo jumbo.

Core parking is, at its simplest, a power saving mechanism. First, a bit of history.

Consumer CPUs have long had low-power sleep states. For a while, these low power states required the entire CPU to halt execution; other components could often be powered off as well. When multi-core CPUs were developed circa 2005, these low power states required each core to halt collectively. Independent speed stepping allowed each core to operate at an independent clock multiplier and VID, allowing fairly effective power management, but execution was still a global binary. This means that cores that were as "idle" as design permitted still accessed L2/L3 cache and still drew power.

Core parking allows an operating system to completely shut off a core such that it no longer performs any function and draws little to no power. When it becomes desirable to do so, the operating system can then wake up the core(s) and speed step them to its heart's content.

The devil, at least as far as real time gaming performance is concerned, is in the details. Specifically, when it becomes desirable to either park or unpark a core. All modern consumer operating systems use some variant of a preemptive multi-level priority queue scheduling algorithm to perform thread scheduling.

In the general case, each thread (there may be thousands globally) is either ready and waiting to be scheduled on a logical processor, or is waiting for a system call to complete (the time may be indeterminant, such as when a process sleeps while waiting for an interrupt). Higher priority threads will always be scheduled first and will displace lower priority threads when they go from waiting->ready. Following this logic, low priority threads will only be scheduled if no higher priority threads are ready.

An audit of the system's ready threads will reveal how long each has been outstanding (waiting to be scheduled) and this information can be used inconjuction with power management policies to make intelligent decisions about processor power states.

High priority threads, such as those that handle user IO are usually not computationally intensive, but they are time sensitive. They need to be scheduled quickly otherwise the system will appear sluggish.

Low priority threads, such as those that handle the heavy math involved in compression/decompression, encoding/decoding/transcoding, and simulation will gobble up CPU time, but unless they're feeding a real time application such as a media player it's not critical that they be scheduled within a certain time window. Prime95 number crunching threads have no business clobbering sound processing threads.

If too many high-priority threads end up waiting too long, parked cores can be woken up to improve performance, or unparked cores can be stepped up. If most scheduling is low-priority or idle-priority, cores can be stepped down or parked to save power.

The trouble with some video games is that interlocking threads of differing priorities combined with poor application-level tuning can confuse the operating system into thinking that it's making intelligent power management decisions when it really isn't. It may think that it's servicing threads fast enough because it has no insight otherwise; or it may take the time to unpark a core only to park it again shortly. This is a tuning issue that's hard to nail down perfectly.

All that these "core unparkers" do is tweak a few power management settings so that the operating system (usually Windows) will never park cores. It will continue to step them up and down, but since speed stepping is much more responsive than parking, it tends to result in a net increase in system responsiveness at the expense of power consumption