Skip to content

P/E hybrid cores and the Windows scheduler

Verified 2 min read

How Windows 11 treats performance and efficiency cores, why background work lands on E-cores, and what processor groups mean above 64 logical CPUs.

Tested onPro (26H2) · Build 26300.9457 · x64
E1
Build
26300.9457
Edition
Pro (26H2)
Architecture
x64
Support
Documentation (E1)
Evidence
E1Official documentation
Verified
2026-10-29
Page type
Concept

A hybrid CPU has two kinds of core in one package: P-cores (highest single-thread) and E-cores (area-efficient, better multi-thread per watt). The operating system must know which is which, because the hardware cannot schedule threads by itself.

Windows 11 is built for this: it reads the CPU’s core classification and steers work accordingly. Windows Server and older Windows builds understand the topology less well, which is why “same CPU, different OS” can behave differently under load.

  • Put latency-sensitive, foreground work on P-cores.
  • Put background and throughput work on E-cores.
  • Keep the whole package inside power and thermal limits.

Practical consequences you can observe without a benchmark:

Symptom Likely cause
A background build slows the foreground app less than expected It is being placed on E-cores — by design
An old game stutters on a hybrid CPU Scheduler/anti-cheat interaction, not “E-cores are slow”
A VM gets uneven performance vCPU placement across P and E cores
A single-thread task runs slower than a review showed Power limit, thermal limit, or the thread landed on an E-core

None of these prove a hardware fault. They are scheduling and power decisions.

Windows organises logical processors into processor groups of up to 64. A process runs inside one group unless it is written to span groups.

  • Most consumer CPUs stay under 64 logical processors, so you never notice.
  • Workstation/server parts above 64 logical processors expose multiple groups, and single-threaded apps cannot use the extra groups.
  • This is why some heavily-threaded workloads scale worse than the core count suggests.

Check your topology:

Terminal window
Get-CimInstance Win32_Processor | Select-Object Name,NumberOfCores,NumberOfLogicalProcessors
Get-CimInstance Win32_ComputerSystem | Select-Object NumberOfProcessors,NumberOfLogicalProcessors
# group count (0-based); >1 means you crossed the 64-CPU boundary
(Get-CimInstance Win32_ComputerSystem).NumberOfLogicalProcessors
  1. Gaming: P-core count and single-thread performance matter more than total cores. A 6P+8E part can beat an 8P part in some games and lose in others — reviews must be read per title, not as a single score.
  2. Compiling: E-cores are genuinely useful; total throughput scales with them.
  3. Virtualisation: vCPU count vs P-core count is what matters for latency-sensitive VMs; over-committing E-cores hurts interactive VMs.
  4. Servers: check that your hypervisor and guest OS version understand the topology before standardising on a hybrid part.
Terminal window
# 1. is the CPU throttling? compare these under load
Get-Counter '\Processor Information(_Total)\% Processor Performance'
Get-Counter '\Processor Information(_Total)\% of Maximum Frequency'
# 2. what is actually running hot
Get-CimInstance Win32_PerfFormattedData_PerfProc_Process |
Sort-Object PercentProcessorTime -Descending | Select-Object -First 8 Name,PercentProcessorTime
# 3. confirm the core layout the OS sees
Get-CimInstance Win32_Processor | Format-List Name,NumberOfCores,NumberOfLogicalProcessors,MaxClockSpeed

If % Processor Performance sits well below 100 under sustained load, you are power/thermal limited — a different problem from scheduling, and the one to fix first.

E1. The scheduler behaviour described here is documented and observable, but this site has not benchmarked hybrid CPUs on bare metal, so it publishes no P-core/E-core performance numbers.

Sources