Type “game stutter fix” into any forum and someone will tell you to disable CPU core parking. Windows puts idle cores to sleep, waking one takes milliseconds, and those milliseconds are supposed to land in the middle of your frames. We stopped repeating the claim and measured it on a real desktop. Here is what actually happened, and how to find out in 30 seconds whether parking even runs on your PC.
What core parking is supposed to do
Core parking is a Windows power feature. Under light load the scheduler funnels work onto a few cores and lets the rest drop into a deep sleep state. A parked core draws almost nothing. The catch is the wake path: when load spikes, Windows must unpark cores before threads can run on them, and tweak guides put that delay anywhere from 1 to 15 ms. If that fired mid-game, you’d feel it. At 144 Hz your frame budget is 6.9 ms, so one slow wake means a dropped frame. That is the entire pitch behind the tweak: keep every core awake, never pay the wake cost, never stutter.
What we measured on a real desktop
The testbed: an Intel Core i9-14900F (8 P-cores, 16 E-cores, 32 threads), Windows 11 Pro 24H2, a desktop on wall power, stock Balanced plan reset to Microsoft’s factory values. We watched the per-core Parking Status performance counters, sampled clocks at idle and under a 32-thread load, and ran a burst test that counts how much work a single thread finishes in each 20 ms window after the CPU sat idle.
Then we applied the standard tweak, the same four values every guide and every unparking tool changes: minimum unparked cores to 100% for both core classes, energy performance preference to 0.
| Measurement | Stock Balanced | Parking disabled |
|---|---|---|
| Parked cores at idle | 0 of 24 | 0 of 24 |
| Parked cores in power saver mode | 0 of 24 | not tested (nothing to park) |
| All-core load clocks | 5.5 GHz P, 4.3 GHz E | 5.5 GHz P, 4.3 GHz E |
| Single-thread speed in the first 20 ms after idle | 96% of max | 95% of max |
Zero cores parked. Not at idle, not in power saver mode, not in a single sample. The tweak changed nothing because there was nothing for it to change. The burst rows tell the same story: this CPU reaches about 95% of full single-thread speed inside the first 20 ms either way. Boost ramps faster than the folklore assumes.
Why nothing was parked
The defaults explain part of it. On wall power, Windows 11 ships Balanced with minimum unparked cores for the efficiency class at 100%. That forbids E-core parking outright. P-cores can park on paper, yet ours never did, not even with the power mode slider set to Best power efficiency. The engine itself is alive. When we tightened the parking caps by hand, Windows parked 24 of 32 threads within seconds. That’s the screenshot below. It works. It just never fired at stock on this box. Another machine can choose differently. Same Balanced plan, different CPU, driver stack, or Windows build, and cores start parking for real. This very desktop parked cores on the same default plan in an earlier Windows setup. So treat our zero as one data point and check your own machine before you conclude anything.
What parking costs when it does fire
Since stock refused to park, we forced the issue: we tightened the parking caps until Windows kept only 8 of 32 threads awake, then measured three states with two tools. The 7-Zip benchmark (the MIPS rating CPU reviews have quoted for years) covers throughput. Our own frame simulator covers pacing: eight worker threads chew a fixed slice of integer math at a 144 Hz cadence, 4300 frames per run.
| Metric | Stock | Parking active (24 of 32 parked) | After the script |
|---|---|---|---|
| 7-Zip rating, 32 threads | 175,111 MIPS | 71,120 MIPS | 175,695 MIPS |
| 7-Zip rating, 1 thread | 8,070 MIPS | 7,957 MIPS | 8,227 MIPS |
| Frame time, p99 | 5.3 ms | 5.3 ms | 4.7 ms |
| Worst frame | 6.5 ms | 17.3 ms | 5.4 ms |
| Frames over the 6.9 ms budget | 0% | 0.14% | 0% |
Read the parked column carefully, because it is not a uniform loss. Single-thread speed did not move. The median frame even got quicker, since all eight workers crowded onto the awake P-cores instead of spreading across E-cores. The damage sits in two places. Multithreaded throughput fell 59% with 24 of 32 threads asleep, so 7-Zip kept less than half its score. The frame tail is worse. Worst frame jumped from 6.5 to 17.3 ms, and one frame in 700 missed the 144 Hz budget outright. That is micro-stutter, written out in numbers. Averages look healthy while spikes ruin the feel.
Be fair to Windows here: our caps held those cores parked through the entire run, and stock parking never behaves that way. A default setup wakes parked cores under sustained load, so its real cost lands in the first moments of a burst, not across a long benchmark. Read the parked column as the ceiling, not the typical bill.
Then we ran the script on top, with the tight caps still in place. Parking went to zero anyway (the minimum it sets overrides the cap), the 7-Zip score returned to 175,695 MIPS, and the frame tail turned into the cleanest of all three runs. That is the honest case for the tweak: it does not add speed a healthy machine already has, it removes a failure mode. Want to reproduce our numbers? The 7-Zip side is one command, 7zr b 3 -mmt32, and the frame simulator is one PowerShell file, bench.ps1 in the utility’s repo, with nothing to install for either.
Check your own PC in 30 seconds
Don’t tweak first. Check first.
- Press Win+R, run
resmon, and open the CPU tab. Watch the per-core list on the right while the machine idles. A sleeping core is labeled Parked, like this:
To photograph that label we tightened the parking caps on our testbed until Windows parked 24 of 32 threads. Grey rows, the word Parked, flat graphs: that is parking in action. If your idle machine looks like this without any forcing, the fix below is for you.
- For the raw settings, run
powercfg /qh scheme_current sub_processorin a terminal and findCPMINCORES(plusCPMINCORES1on hybrid Intel). The value is the minimum share of cores that must stay awake. 0x64 is 100%, which means parking is off.
If nothing ever reads Parked while your PC idles, core parking is not your stutter, and the real cause lives elsewhere. In online games that cause is often the connection, not the CPU: a ping that spikes under load feels exactly like a stuttering rig. Our bufferbloat guide shows how to catch that in two minutes.
Where parking is still real
- Laptops on battery. The DC defaults allow deep parking and vendors tune them more aggressively. This is the one common setup where you can watch cores park in real time.
- Windows 10 and older systems with pre-hybrid CPUs. The aggressive defaults lived there, and plenty of those machines still run.
- OEM power plans. Prebuilt desktops sometimes ship vendor plans with parking thresholds a clean Windows install never uses.
- AMD X3D chips with two dies. A 7950X3D parks its second CCD on purpose so games stay on the V-Cache cores. Leave that alone: unparking it moves game threads off the fast cache and costs you frames.
How to disable it, when the check says you should
If your check showed parked cores and you game plugged in, turning parking off is safe and reversible.
The fastest route is cpu-parking-disabler, a small open source PowerShell script (MIT licensed). One line in a terminal:
irm https://raw.githubusercontent.com/vadyaravadim/cpu-parking-disabler/main/cpu-parking-disabler.ps1 | iexIt asks for admin rights, saves a backup of your power scheme to the Desktop, then applies the four values from our test. Undo is one command: powercfg -import with the path to that backup file. The README walks through verification and rollback.
Prefer typing it yourself? The script wraps these commands:
powercfg -setacvalueindex scheme_current sub_processor CPMINCORES 100
powercfg -setacvalueindex scheme_current sub_processor CPMINCORES1 100
powercfg -setacvalueindex scheme_current sub_processor PERFEPP 0
powercfg -setacvalueindex scheme_current sub_processor PERFEPP1 0
powercfg -setactive scheme_currentRepeat them with -setdcvalueindex if you want the same behavior on battery. If you’d rather click through a GUI with per-plan toggles, ParkControl by Bitsum covers the same settings. Whichever route you pick, rerun the 30 second check afterward: CPMINCORES should read 0x64 and resmon should never show Parked again.
What the tweak costs
On a machine where cores actually parked, keeping them all awake raises idle power draw and idle temperatures a little, which on a desktop mostly means slightly more fan noise. On a laptop it means shorter battery life, so leave the battery profile alone. Nothing about the tweak touches voltage or clock limits, so there is no stability or warranty angle. And if it does nothing for you, as it did nothing on our testbed, revert it and keep hunting the real cause.