内存分配与竞争实战：从伙伴系统到PCIe BAR排障

1. 内存分配的底层路径：从malloc到伙伴系统

1.1 用户态malloc到底在干什么

先聊一个最容易被忽视的事实：malloc并不是每次调用都会立刻向操作系统申请内存。大多数情况下，glibc的malloc只是在一个用户态维护的内存池里翻找一块合适的空闲块，如果找到就直接返回地址，整个过程不涉及系统调用。只有当前内存池不满足需求时，malloc才会通过brk或mmap向内核要新的内存段。

这是一个典型的"批发与零售"模型。内核是批发商，按页（通常是4KB）批量放货；glibc是零售商，把一页拆成几十个大小不等的块卖给应用。这样做的好处显而易见——系统调用的开销很大，动辄几百纳秒，而用户态分配一块小内存可以在几十纳秒内完成，性能差了近一个数量级。

但问题也随之而来：用户态内存池和内核之间的"批发"节奏，并不总是和应用的释放节奏同步。应用free掉的内存，glibc不一定会立刻还给内核，而是留在池子里复用。这导致很多场景下，我们用top或free命令看到进程的RSS居高不下，但应用实际只用了其中一部分。

如果你在写高并发服务，一定要理解这一层机制。举个例子，我曾经排查过一个服务，看起来内存占用只有200MB，但分配吞吐量极低，每次分配耗时忽高忽低。最后发现问题不在malloc本身，而是应用频繁申请超过128KB的大块内存，触发了mmap阈值，导致每次分配和释放都走一次完整的内核路径。把M_MMAP_THRESHOLD调大之后，性能立刻稳定下来。

1.2 内核里的页分配器：伙伴算法与slab

进到内核这一层，内存分配的核心单位是"页"。伙伴系统（Buddy System）是Linux页分配器的底层框架，它的设计思路很有意思：把空闲页按2的幂次分成不同的链表，比如order-0是1页，order-1是2页连续内存，order-2是4页连续内存，以此类推。分配时，如果请求order-3（8页），而该链表为空，就从order-4里拆一块出来，一分为二，一半返回给调用者，另一半挂到order-3链表上。释放时反向合并，尽可能把相邻的空闲页重新拼成大块。

这个算法的核心优势是合并速度快、外部碎片可控。但代价是内部碎片——请求5页时，伙伴系统只能给8页，多出的3页对应用来说就浪费了。所以内核里绝大多数数据结构分配并不直接走伙伴系统，而是走slab分配器：预先从伙伴系统拿若干页，切成固定大小的对象，然后按对象粒度分配。

slab有一个非常关键的优化叫per-CPU缓存。每个CPU都有一份私有的空闲对象列表，分配时优先从本CPU的列表里取，不需要加锁。这个设计直接降低了多核系统中的锁竞争——后续在竞争问题上还会提到。调试内核内存问题时，/proc/slabinfo和slabtop是很好的观察窗口，可以看到每种内核对象各分配了多少、哪些对象明显异常增长。

1.3 大页、THP与内存映射的隐性坑

页是4KB，但TLB（页表缓存）条目有限，访问大量内存时4KB页会导致TLB频繁失效。于是有了大页（HugeTLB），也就是2MB或1GB的页。大页能显著降低TLB miss，但它的分配路径和普通小页完全不同——需要系统预留，而且分配时机是在启动时或通过/proc/sys/vm/nr_hugepages动态预留。

Linux还有THP（Transparent Huge Pages），目的是让应用程序无感知地使用大页。THP的设计初衷很好，但在某些场景下反而会坑人：后台khugepaged线程会尝试把相邻的小页合并成大页，这个过程需要页表操作和TLB刷新，可能引入不可预测的延迟尖峰。对于延迟敏感的应用（比如数据库、交易系统），我通常建议关闭THP或设置为madvise模式，在明确需要的内存区域才启用大页。这个经验不是拍脑袋——很多数据库厂商的部署手册里都会把"disable THP"列为必做项。

还有一个容易忽略的点是mmap与/dev/zero的配合。很多人以为mmap一定比malloc高效，其实未必。映射大内存时，页表建立的时间、缺页中断的次数、以及换页时的IO开销，都可能让mmap退化为性能陷阱。正确的做法是：小对象用malloc，大块连续内存、需要文件映射或进程间共享时再用mmap，同时注意MAP_POPULATE和MAP_NORESERVE这些标志对缺页行为的影响。

2. 竞争不是玄学：多线程分配内存时的隐形战场

2.1 线程安全分配器的设计差异与选型

当多线程同时调用malloc时，用户态分配器必须在"线程安全"和"性能"之间找平衡。最朴素的做法是在整个内存池上加一把大锁，一次只让一个线程操作。这种方案在低并发下没问题，线程一多就变成"锁竞争地狱"——所有线程排队等着拿锁，分配吞吐量断崖式下跌。

glibc老版本的实现就接近这种大锁模型，后来引入了arena机制：每个arena有一把独立的锁，线程可以分散到不同的arena上，减少同一把锁上的竞争。但这引入了新的问题——线程和arena之间是动态绑定的，如果一个arena的锁被占满，线程会被强制迁移到其他arena，这个迁移本身可能伴随CACHE不友好。

TCMalloc和jemalloc走的是另一条路：per-thread cache。每个线程优先从自己私有的缓存里分配内存，只有私有缓存不足时才去中央堆（central heap）取一批。这样做的好处是绝大多数分配/释放操作完全不涉及跨线程同步，天然免疫锁竞争。

我做过一个实测对比：一个16线程、每线程高频分配和释放8~64字节小对象的程序，glibc的吞吐量约为每秒2000万次分配，TCMalloc能达到1.2亿次左右，jemalloc也有9000万次。差距非常明显。但要注意，per-thread cache本身会占用更多内存，因为每个线程都要保留一部分空闲块。内存敏感的场景需要权衡：是省内存还是省时间。

2.2 锁竞争、饥饿与优先级反转

锁竞争是内存分配领域最常见的性能杀手，但很多人对它的理解停留在"等待锁解锁"这个表面。实际上，锁竞争的成本不只是等待时间，还有三个附加成本：

• 上下文切换：如果锁的waiter被挂起，线程需要切走，等到锁释放再切换回来，这个过程每次损失微秒级时间。
• CACHE行伪共享：多个线程虽然在等同一把锁，但锁变量所在的CACHE line被不停地在CPU之间"弹跳"，每次弹跳都要做缓存一致性协议同步。
• 调度抖动：高竞争下线程的调度顺序无法保证，可能出现"线程A拿锁干活、线程B拿锁干活、线程A又在等锁"的乒乓效应。

还有两个更隐蔽的问题：饥饿和优先级反转。饥饿指的是低优先级线程长期拿不到锁，而高优先级线程不断抢到锁。优先级反转则是低优先级线程持有锁时，高优先级线程阻塞等锁，导致高优先级任务反而慢。

应对这些问题的标准做法是：减小临界区、用读写锁而不是互斥锁、优先考虑无锁数据结构。不过无锁不是银弹——无锁队列虽然避免了锁等待，但CAS循环本身在高竞争下会导致大量重试，性能也可能不如一个好的锁方案。我见过一些团队迷信无锁，结果在128核机器上性能反而比用锁差，因为CAS的retry风暴让总线带宽被塞满了。

2.3 用竞争定位矩阵快速锁定问题层面

"竞争"在计算机系统里其实不是一个单一概念。我在排查问题时会用一个简单的矩阵来定位竞争发生在哪个层面，避免陷入细节泥潭。

这个矩阵帮我快速判断问题应该从哪个工具链入手。比如，如果perf lock显示用户态锁的等待时间占比超过30%，就值得考虑换分配器或调整线程模型；如果锁等待很低，但分配延迟依然不稳定，就要怀疑是不是落在内存带宽竞争上——这时加再多的锁优化都白搭，得调整NUMA亲和性或数据布局。

3. 实战复盘：Linux内核为什么给PCIe桥接器分配不了BAR空间

3.1 BAR空间是什么：PCIe设备向CPU"要地址"的方式

PCIe设备要和CPU通信，需要把自己的寄存器、门铃、DMA缓冲区暴露给CPU的物理地址空间。这个过程通过BAR（Base Address Register）实现：设备的每个功能（Function）有最多6个BAR寄存器，每个BAR声明一段地址空间的大小和属性（内存映射或IO映射）。系统启动时，固件或操作系统枚举PCIe总线，为每一个BAR分配一段唯一的CPU物理地址区间，然后把地址写入BAR寄存器。

BAR空间分配的约束条件非常苛刻：每段地址区间必须是该BAR大小的整数倍对齐，同时不能与其它设备或系统保留区域重叠。这意味着地址空间不是简单"够不够大"，而是要看"碎片化程度"。系统内存越大、PCIe设备越多、设备BAR越大，碎片化越严重。

3.2 这次的失败现象：dmesg与lspci能告诉我们什么

故障现场是这样的：服务器在操作系统启动阶段频繁报错，dmesg里刷出类似下面的信息：

code复制pci 0000:02:00.0: BAR 1: no space for [mem size 0x00080000 64bit pref]
pci 0000:02:00.0: BAR 1: failed to assign [mem size 0x00080000 64bit pref]

这两行日志的含义是：内核在PCIe枚举阶段尝试为某个设备的64位预取内存BAR分配512KB地址空间，但找不到合适的位置。出现这个错误后，设备声明了BAR，但实际没有分配到地址，驱动初始化时访问该BAR区域就会触发IO错误或中断风暴。

接下来用lspci -vvv观察，能看到这个设备的状态是"BAR 1: not assigned"或者显示大小但地址为0。同时查看系统所有PCI设备的资源占用，确认PCI地址空间的整体布局：

bash复制lspci -vvv | grep -E "Region|Bus:" | head -50
cat /proc/iomem | grep "PCI Bus"

3.3 排查链路：从IOMMU到预留窗口

回到这个问题的本质：内核给PCIe设备分配BAR空间，采用的是一个线性扫描映射算法。它从PCI域的最高地址往下扫描，尝试将每个BAR放入满足对齐和大小的空闲区间。这个算法在地址空间充足时不会出问题，但在以下三种情况会失败：

1. PCI域地址空间小于系统物理内存范围：当系统物理内存非常大（比如超过64GB），而PCI域资源窗口只有4GB或不足时，映射空间天然不足。特别是32位非预取BAR，只能落在4GB以下，这一区域特别拥挤。
2. BIOS/固件预留了大量MMIO区域：为了支持ACPI、显卡、NVMe等设备，固件会在PCI域内保留大片区域，这些保留区域不可调用。
3. PCIe桥的窗口无法覆盖下游设备：这是热词里"pci bridge无法给pcie桥接器分配足够内存映射空间"的直接场景——上游桥的窗口（Bus的资源窗口）已经决定了它能向下游设备分配的范围，如果这个窗口本身太小，下游设备无论BAR多合理都无地可放。

排查时我习惯按这样一步步来：

bash复制# 查看PCI域的总窗口信息
sudo lspci -s 00:01.0 -vvv | grep -A5 "Bus: primary"
# 查看上游桥资源裁剪结果
sudo cat /sys/bus/pci/devices/0000:00:01.0/resource
# 查看系统全部PCI空间分配
sudo cat /proc/iomem | grep -E "PCI|MMIO"

一个很典型的现象是：/proc/iomem里PCI Bus 1到Bus N的区域被缩小到很小的范围，导致大量设备BAR无法分配。这种现象在BIOS提供的ACPI DSDT表有缺陷或者BIOS版本太旧时尤其常见。

3.4 修复与规避：BIOS、内核参数与实际工程取舍

针对BAR空间分配失败，我总结出几个从软件到硬件的递进处理方案。

方案一：加内核参数重新审视预留空间

启动时添加pci=realloc参数，强制内核在启动阶段重新分配所有BAR空间。这个参数能解决一部分因BIOS预留不合理导致的窗口问题。

bash复制# /etc/default/grub 中添加
GRUB_CMDLINE_LINUX="pci=realloc"
sudo update-grub

方案二：调整PCI资源窗口的大小

某些BIOS允许在PCI Subsystem Settings中手动调整MMIO窗口大小和高位预取窗口的地址范围。比如把"MMIO High Base"从64GB调高到128GB，给64位BAR留出足够空间。

方案三：减少设备数量或BAR占用

如果服务器上插了多张GPU卡，每张卡都要8GB以上的BAR空间，可以考虑在BIOS里关闭不需要的板载设备（比如板载声卡、第二网卡），释放一些窗口。

方案四：换用更大的物理地址空间结构

对于严重超配的场景，比如4张双槽GPU配上大内存，唯一可靠的方案是换支持更大地址窗口的平台，或者改用支持Resizable BAR的设备和BIOS组合——这样GPU能按实际需要动态申请BAR大小，而不是按固定最大尺寸占用。

我印象很深的一次，是给一台8卡GPU服务器排障，明明系统有1TB内存，但PCIe枚举总是失败。最后发现是BIOS里"Above 4G Decoding"没有开启，64位BAR空间全被限制在4GB以下。开启后问题直接消失。这个选项在老旧BIOS里藏得很深，名字通常是"Above 4G Decoding"或"Memory Hole for PCI MMIO"。

最后还要提一个容易忽视的点：如果在虚拟机里遇到类似报错，优先检查宿主机是否给虚拟机预留了足够的MMIO空间，以及QEMU/KVM参数里的-device pcie-root-port数量是否足够——每个root port都会占用桥窗口资源，窗口不够同样会报BAR分配失败。

4. 硬件侧的竞争冒险：从毛刺到亚稳态，看清内存时序的底线

4.1 数电竞争冒险的本质：同一次变化，两条路径

"竞争冒险"这个词源自数字电路。它描述的是这样一个场景：同一个逻辑信号从源头出发，经过两条不同的路径到达目的地，一条路径经过的门的级数少（延迟短），另一条路径经过的门的多（延迟长），结果信号到达时间不一致，导致输出在某个瞬间出现不期望的毛刺（glitch）。

举例来说，一个组合逻辑电路要实现F = A xor B，当A和B同时从0跳变到1时，如果两条输入路径延迟不一致，输出端可能在瞬态出现一个短暂的0，虽然稳定态输出应该是0。这个短暂的低电平就是毛刺。

毛刺的影响范围取决于下游接的是什么。如果下游是组合逻辑，毛刺可能传播一段后被后续电路抑制；如果下游是触发器或锁存器，毛刺就可能被采样，导致整个系统的状态错误。这也是为什么数字电路设计规范里对组合逻辑有"最小脉宽"和"建立时间"约束。

4.2 建立时间、保持时间与亚稳态：内存读写为什么需要"时序约束"

内存接口的竞争冒险，集中体现在触发器的建立时间（Setup Time）和保持时间（Hold Time）上。

建立一个概念：触发器在时钟上升沿采样数据D端。为了让采样结果稳定，数据D必须在时钟沿到来之前提前T_setup稳定，并在时钟沿之后继续保持T_hold不变。如果在采样窗口内数据发生跳变，触发器就会进入亚稳态（Metastability）——输出既不是确定的0也不是确定的1，而是一个介于两者之间的电平，并且可能持续很长时间。

同步逻辑里，只要满足建立时间和保持时间约束，数据就能被正确采样。但异步接口（比如不同时钟域的握手信号）或外部输入信号，就可能违反这些约束。实际工程中经典的处理方式是在进入同步逻辑前加两级触发器同步器，用"多一级寄存器"换"亚稳态不传播"。这是FPGA/ASIC设计入门必学的技巧，也是竞争冒险在实际硬件设计中的最常见应对。

4.3 软件竞争与硬件竞争的分界线

写软件的人听到"竞争"第一反应是竞态条件（race condition），写硬件的人听到"竞争"第一反应是竞争冒险（race hazard）。这两个概念在思想上是相通的——都是"多个事件同时作用，结果取决于时序顺序"——但处理方式完全不同。

软件竞争的解法是做"互斥"和"原子性"：保证一段代码同一时刻只有一个线程执行，或者一个操作要么完整执行要么不执行。硬件竞争的解法是做"时序约束"和"同步"：保证数据在采样窗口内稳定，或者在跨时钟域时用同步器消除亚稳态。

我用一个类比来理解这个区别：软件竞争就像两个人同时用同一个账号提交订单，解决的办法是加锁或加版本号；硬件竞争就像两个人同时按门铃，门铃电路的采样脉冲刚好落在两人的手同时按下的瞬间，解决办法是让门铃在按下的瞬间再多等一会儿再采样——这就是建立时间的概念。

对做内核或系统编程的人来说，理解硬件竞争冒险有助于理解内存屏障（memory barrier）存在的意义。编译器可能重排指令、CPU可能乱序执行、写缓冲区可能延后写回，这些优化在单线程下无害，多线程共享内存时就可能把"顺序"打破。smp_mb()、READ_ONCE、WRITE_ONCE这些原语的作用，本质上就是把"同步"这件事从软件契约映射到硬件时序上。

4.4 竞争定位矩阵的工程化应用

前面提到过竞争定位矩阵，这里展开说一下具体怎么用。

假设一个服务出现周期性延迟抖动，我第一步做的不是看代码，而是先判断抖动发生在哪个层面。一个简单的判断方式是：用perf stat看锁竞争、用bpftrace追踪kmalloc调用链、用/proc/interrupts看中断分布、用pidstat看CPU迁移。把这组数据套进矩阵，基本一眼就能定位到问题域。

举个例子，一次内存延迟毛刺的排查：perf显示用户态锁等待极低，但cycles里的stalled-cycles-frontend非常高，同时CPU迁移次数异常多。矩阵对应到的是"内存带宽竞争"或"CPU调度竞争"层，而不是锁层。最后用turbostat确认多个CPU核在抢同一个内存控制器的带宽，根本问题出在NUMA拓扑和数据布局不匹配。如果当时执着于优化锁，方向就完全错了。

这个矩阵的最好用法是作为团队排查文档的起点，每次遇到新问题都先填一列观测数据，再决定该深入哪个方向。

5. 几个我沉淀下来的内存竞争排查习惯

5.1 观察指标要分层，不要只看均值

排查内存分配性能问题，最容易犯的错是看平均延迟。平均延迟会把偶发的高延迟稀释掉，掩盖真正的竞争问题。我现在习惯用p99.9和max作为核心指标，同时记录分配调用的频率分布。如果p99.9远高于p50，几乎可以断定存在竞争或锁抖动。

配合perf sched record和perf timechart，能看到线程的调度时间线和运行时间线，锁竞争导致的线程唤醒延迟会非常直观地暴露出来。

5.2 验证分配器选型时，一定要在真实负载下测

我在前面推荐过jemalloc和TCMalloc，但必须强调：分配器的优劣高度依赖分配大小、线程数、分配/释放模式。同一个分配器，在16线程、32字节小对象场景下是神，换成128线程、512字节混合大小场景可能就很平庸。

我通常的做法是：先用malloc-bench或tcmalloc自带的benchmark做初步对比，但最终决策必须用真实负载架构在staging环境跑48小时以上，观察p99.9延迟和RSS增长趋势。有一个项目里，jemalloc的延迟指标比TCMalloc好，但RSS不断增长，后来发现是jemalloc为每个线程保留的缓存在高线程数场景下内存消耗过大，最终换了配置或限制脏页回收。

5.3 排查PCIe BAR问题时，一定保留完整的设备和资源快照

BAR空间问题的复现不总是稳定，有时改一个BIOS设置就消失了，有时重启后又复发。我习惯在首次排查时就保存完整的现场信息：lspci -vvv完整输出、/proc/iomem、BIOS版本、内核版本以及报错前后的dmesg。这套快照配合时间线，比什么都管用。很多BIOS交互问题过了几天再回去看，当时没保存的信息就是找不回来了。

5.4 任何"自动优化"都值得保留一个手动开关

THP是一个典型例子。自动大页合并的初衷是好的，但它的后台扫描线程在某些负载下会制造延迟抖动。数据库社区很早就在部署文档里写了"disable THP"，不是因为他们不懂大页的好处，而是因为在OLTP这种延迟敏感场景，稳定比峰值更重要。

这一类"自动优化"在内存分配领域很多：glibc的arena扩展策略、内核的zone_reclaim、KSM内存去重、devices的Resizable BAR等等。我的建议是：了解每个自动机制的行为模型，在性能测试中主动开关对比，而不是保持默认设置不动。没有银弹，只有针对工作负载的取舍。