多核CPU架构基础：为什么你的中断亲和性调不好？
大家好，我是老K。在系统性能优化这行摸爬滚打了十几年，我经常在项目中听到一个误解：“多核CPU不就是把几个CPU核心焊在一起吗？” 真这么想，那你调中断亲和性大概率要翻车。今天咱们先把底层的砖砌好。
多核CPU的架构，说白了就是“多个大脑怎么分工协作”。你想想看，如果每个核心都抢着去处理中断，或者缓存数据都不共享，那性能反而会崩。嗯，我这里说的都是实战中踩过的坑。
1.1 物理结构：核心不是孤岛
先看一张我手绘的架构简图。这张图我优化了好几版，就是为了让你一眼看清数据是怎么在核心间“串门”的。
1.2 缓存层次：谁快谁慢，心里要有数
我个人习惯把多核处理器的缓存比作“团队办公桌”。L1是手边的笔记本，L2是工位旁的文件柜，L3是整个团队的公柜，内存就是隔壁楼的档案室。
跑个数据你就有感觉了：
| 存储层级 | 典型大小 | 访问延迟（时钟周期） | 位置属性 |
|---|---|---|---|
| L1 Cache | 32KB - 64KB | 3-4个周期 | 核心私有 |
| L2 Cache | 256KB - 512KB | 10-12个周期 | 核心私有 |
| L3 Cache | 8MB - 32MB | 30-40个周期 | 所有核心共享 |
| 主存 (DDR5) | 16GB - 256GB | 100-300个周期 | 经过内存控制器 |
你看这个延迟差异。L1命中是3个周期，内存访问可能需要两三百个周期。差了百倍！我之前做一个网络包处理项目，就因为缓存行对齐没处理好，性能直接腰斩。
避坑指南： 我曾经在调试一个高并发数据库时，发现某个核心总是比别的核心慢一大截。查了半天，发现是中断亲和性没绑好，导致该核心频繁被网卡中断打断，L1缓存被冲刷得干干净净。性能损失高达40%。
1.3 内存控制器：从北桥走进CPU内部
记得老主板上有颗北桥芯片吗？内存控制器就在那。现在呢？Direct Connect架构把它集成到CPU内部了。好处很明显——内存延迟大幅降低。
但有个坑：多路服务器里，每个CPU只能直接访问自己“脚下”的那块内存。访问远端内存要走QPI/UPI总线。这在NUMA架构下特别关键。你调中断亲和性时，必须考虑中断源和内存的物理位置。
举个例子：
- 本地内存访问： 大概100ns延迟
- 跨片内存访问： 可能上升到200-300ns延迟
所以，我建议你在绑定中断时，优先考虑把中断和它要处理的数据放在同一个物理CPU上。
1.4 核心间通信机制：怎么喊话才不打架？
核心之间不是哑巴，他们需要说话。常见的通信方式有这么几种：
核心通信方式对比：
- 共享内存（最常见）： 通过L3缓存或内存交换数据。问题是缓存一致性协议（MESI等）需要广播消息，核心一多，总线就吵了。我记得一个项目里8核CPU跑满时，缓存一致性流量占掉了总线的30%。
- 核间中断（IPI）： 一个核心可以直接向另一个核心发中断。比如你要把某个任务迁移到另一个核心，就用IPI通知它。这玩意儿在中断负载均衡里很有用。
- 硬件Ring Bus / Mesh网络： 现代CPU内部的数据通路。Intel的Ring Bus在核心少时延迟低，AMD的Mesh在核心多时扩展性好。
- 内存映射IO（MMIO）： 外设（比如网卡、NVMe硬盘）通过PCIe地址空间直接和核心通信。DMA用的就是这条路。
你想想看，如果网卡产生一个DMA中断，通过PCIe连到CPU，再通过Interrupt Controller（APIC）找到目的核心。这一路如果路径没优化，中断响应时间就会飙升。
1.5 总结：记住这三点，后面学习不踩坑
我在讲课时经常说：理论不清，实践上不去。第一章你只要把下面三条刻在脑子里：
| 核心知识点 | 为什么重要 |
|---|---|
| 缓存层次与延迟差异 | 中断亲和性绑错核心，可能导致缓存反复被冲刷，性能断崖下跌 |
| 内存控制器位置 | NUMA架构下，绑定时必须考虑“内存插在哪个CPU上” |
| 核心间互连与IPI机制 | 中断分发路径决定了中断响应的延迟上限 |
一点建议： 你在做任何中断亲和性优化之前，先用工具把CPU拓扑跑一遍。比如Linux下的lscpu，看看你的cache topology和NUMA node是怎么分配的。心里有张地图，打仗才不慌。
好了，这一章就这么多。多核CPU的架构听起来复杂，其实你抓住“数据怎么存、数据怎么走、核心怎么喊话”这三点，就能应付大多数优化场景。后面我们遇到具体的中断亲和性难题，我会带着你一步步拆解。