# P/E hybrid cores and the Windows scheduler

> 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 on**

- Build: 26300.9457
- Edition: Pro (26H2)
- Architecture: x64
- Evidence: E1
- Verified: 2026-10-29

## The short answer

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.

## What the scheduler is trying to do

- 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.

## Processor groups: the 64-CPU wall

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:

```powershell
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
```

## Where this changes your buying decision

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.

> **Tip: Pin work only when you must**
>
> `Start-Process -ProcessorAffinity` or Task Manager affinity can pin a process to a set of cores. It is a diagnostic tool, not a tuning strategy: pinning a game to P-cores can help stutter investigations, and permanently pinning services usually makes things worse.

## Test whether it is scheduling or hardware

```powershell
# 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.

## Lab boundary

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

- [Microsoft Learn — Processor groups](https://learn.microsoft.com/en-us/windows/win32/procthread/processor-groups)
- [Microsoft Learn — Windows processor requirements](https://learn.microsoft.com/en-us/windows-hardware/design/minimum/windows-processor-requirements)
- [Microsoft Learn — Windows 11 requirements](https://learn.microsoft.com/en-us/windows/whats-new/windows-11-requirements)

---

Source: https://windows.homes/en/hardware/cpu/hybrid-cores/