大小核与 Windows 调度器

核验于 2026-10-292 分钟阅读

Windows 11 如何对待 P 核与 E 核、后台任务为什么跑到 E 核、以及超过 64 个逻辑处理器后的处理器组限制。

测试环境Pro (26H2) · 版本号 26300.9457 · x64

版本号: 26300.9457
版本: Pro (26H2)
架构: x64
支持: 文档（E1）
证据: E1官方文档
核验日期: 2026-10-29
页面类型: 概念

一句话结论

混合 CPU 在一个封装里放两类核心：P 核（最高单线程）与 E 核（面积效率高、多线程每瓦更好）。必须由操作系统知道谁是谁，因为硬件自己不会按线程调度。

Windows 11 就是为这个设计的：它读取 CPU 的核心分类并据此引导工作负载。Windows Server 和更老的 Windows 对该拓扑理解较弱，所以“同一颗 CPU、不同系统”在负载下表现可能不同。

调度器想做什么

把延迟敏感、前台的工作放 P 核。
把后台、吞吐型工作放 E 核。
让整个封装待在功耗与温度限制内。

不跑分也能观察到的现象：

现象	可能原因
后台编译对前台应用的影响比预期小	它被放到 E 核——这是设计意图
老游戏在混合 CPU 上卡顿	调度器与反作弊交互，不是“E 核慢”
虚拟机性能不均	vCPU 被分到 P 核与 E 核
单线程任务比评测慢	撞功耗墙/温度墙，或线程落在 E 核

这些都不能证明硬件故障，它们是调度与功耗决策。

处理器组：64 CPU 的墙

Windows 把逻辑处理器分进最多 64 个一组的处理器组。进程默认只在一个组里跑，除非专门写成跨组。

消费级 CPU 通常在 64 逻辑处理器以内，所以感觉不到。
超过 64 逻辑处理器的工作站/服务器部件会暴露多个组，单线程应用用不到额外组。
这就是为什么某些重线程负载的扩展性不如核心数看上去那么好。

查看拓扑：

Get-CimInstance Win32_Processor | Select-Object Name,NumberOfCores,NumberOfLogicalProcessors
Get-CimInstance Win32_ComputerSystem | Select-Object NumberOfProcessors,NumberOfLogicalProcessors

这件事怎么改变购买决策

游戏：P 核数量与单线程性能比总核心数更重要。6P+8E 在部分游戏赢 8P，在另一些输——必须按游戏读评测，不能看总分。
编译：E 核确实有用，总吞吐随它们增长。
虚拟化：vCPU 数量与 P 核数量的比例决定延迟敏感虚拟机的体验；超配 E 核会伤交互型虚拟机。
服务器：标准化到混合部件前，先确认你的 hypervisor 与来宾系统版本理解该拓扑。

分辨“调度问题”还是“硬件问题”

Get-Counter '\Processor Information(_Total)\% Processor Performance'
Get-Counter '\Processor Information(_Total)\% of Maximum Frequency'

Get-CimInstance Win32_PerfFormattedData_PerfProc_Process |
  Sort-Object PercentProcessorTime -Descending | Select-Object -First 8 Name,PercentProcessorTime

持续负载下 % Processor Performance 明显低于 100，说明你撞的是功耗/温度墙——那是另一个问题，而且应该先修。

实验室边界

E1。这里的调度行为有文档依据且可观察，但本站没有在裸机上对混合 CPU 做基准测试，因此不发布 P 核/E 核性能数字。