Linux 内核 CPU 拓扑：topology.c 与 sysfs 导出原理

跑过一次lscpu看到输出里的 Socket、Core、Thread、NUMA node你就已经间接遇到了 Linux 内核里的drivers/base/topology.c。它不是一个具体的设备驱动而是设备驱动模型基础层里的一个“地图导出器”把体系结构层算好的 CPU 拓扑关系整理成/sys/devices/system/cpu/cpuX/topology/下的一组只读属性。做性能优化、排查绑核问题、学习内核调度的人迟早会翻到这个文件。这篇笔记是我实际走读drivers/base/topology.c的记录同时把周边知识串起来sysfs 里每个字段怎么读、数据从哪里来、能用来解决什么问题、以及学习时最容易被绕进去的坑。如果你是想搞清楚lscpu -p背后原理的人或者刚接触内核设备模型的读者这篇内容可以直接当作一份带注释的路线图。1. 先搞清楚 topology 在驱动模型里的位置1.1 drivers/base 是内核设备模型的“底盘”drivers/base这层目录是把 Linux 设备驱动模型撑起来的地方。里面有core.c、bus.c、driver.c、class.c、platform.c还有cpu.c、memory.c、node.c、topology.c这类和具体硬件总线无关的子系统文件。简单说总线驱动、设备驱动负责和硬件打交道而drivers/base负责维护设备、驱动、总线和类之间的关系提供一个统一的框架。topology.c放在这个目录本身就说明了一件事CPU 拓扑不是某个外设总线的私有能力而是和 CPU 设备、内存节点平级的系统级信息。它不直接 read/write 某个寄存器也不做中断处理它的任务只有一个把“CPU 和 CPU 之间怎么排列”这件事从内核计算好的数据里提取出来挂到每个 CPU 设备对应的 sysfs 目录下。很多刚看内核的人会下意识找一个probe函数但topology.c没有传统的struct platform_driver注册。它更像是在subsys_initcall阶段遍历所有可能的 CPU给每个cpuX设备补上一组属性。这种“设备目录已经存在我往里面挂属性”的形式在驱动模型里很典型和普通驱动“注册自己、等匹配、然后初始化”的思路不太一样。1.2 没有统一抽象时会乱成什么样为什么不能每个架构单独导出一套拓扑 sysfs因为不同 CPU 架构描述拓扑的方式差得太远了。x86 有完整的 APIC ID 体系可以从中解码出 package、die、core、thread 层级ARM/ARM64 靠 MPIDR 寄存器里的亲和层级s390 还有 book、drawer 这类更复杂的层级。如果每个架构都按自己的习惯暴露节点用户态工具就惨了lscpu得为每一种平台维护一套解析逻辑内核主线也没办法对这套用户 API 做稳定承诺。topology.c的价值是把“暴露哪些属性”和“这些属性值怎么算”分开。前者在drivers/base/topology.c里统一固定成physical_package_id、core_id、thread_siblings、core_siblings等名字后者交给架构层实现通过topology_xxx(cpu)这样的钩子函数提供具体数值。换句话说架构层只需要回答“某个 CPU 的 package 是多少、core 是多少、哪些 CPU 和它共享同一个核”剩下的 sysfs 格式、位图转换、属性可见性判断都由topology.c统一处理。这也是它在基础层而不是在具体平台驱动目录里的根本原因。2. 手把手看懂 sysfs 里的 CPU 拓扑节点2.1 cpuX/topology 下的属性到底代表什么先找一台 Linux 机器随便挑一个 CPU 看目录ls /sys/devices/system/cpu/cpu0/topology/你会看到一堆文件。常见的有下面这些。属性名含义补充说明physical_package_id物理封装 ID一般对应一个 socket在单 socket 多 die 封装中也用来区分物理封装die_id封装内 die 的编号老内核不一定有这个属性多 die 处理器上更常见core_id物理 core 在 package/die 内的编号注意不等于全局 CPU 编号thread_siblings与当前 CPU 共享同一个物理 core 的 CPU 位图也就是同一个核上的超线程兄弟thread_siblings_list上面的可读列表格式比如0,1core_siblings与当前 CPU 处于同一个物理 package 的所有 CPU 位图历史命名容易误解它表示的是 package 范围core_siblings_list上面的可读列表格式比如0-7die_cpus与当前 CPU 处于同一个 die 的所有 CPU 位图新内核常用die_cpus_list上面的可读列表格式比如0-15package_cpus与当前 CPU 处于同一个 package 的所有 CPU 位图和core_siblings兼容但语义更明确package_cpus_list上面的可读列表格式按 CPU 编号排序的列表我第一次看到core_siblings的时候被名字坑过以为它表示“同一个 core 的兄弟”结果发现里面装的是一个物理 package 内的所有 CPU。后来看Documentation/admin-guide/cputopology.rst才确认这是历史命名带来的历史包袱理解的时候直接把它当成“package 内 CPU 集合”就好。2.2 用命令把这些字段和 lscpu 对上直接读文件是最直观的验证方式topo/sys/devices/system/cpu/cpu0/topology for f in core_id physical_package_id thread_siblings_list core_siblings_list; do printf %-24s: %s\n $f $(cat $topo/$f) done在一台双核超线程机器上输出可能是core_id : 0 physical_package_id : 0 thread_siblings_list : 0,1 core_siblings_list : 0-3这说明 CPU0 和 CPU1 共享一个物理 core而 CPU0、CPU1、CPU2、CPU3 都在同一个物理 package 里。再用lscpu -e看lscpu -e输出里的 CORE 列、SOCKET 列、CPU 列正好能对应上core_id、physical_package_id和全局 CPU 编号。看到这里再回来看lscpu -p的机器可解析格式你会发现它基本就是把 sysfs 的_list文件重新拆开了一遍。thread_siblings这类位图字段用的是内核 cpumask 格式比如00000000,00000003。它不是一个普通十进制数而是按 bit 位映射 CPU 编号bit 0 对应 CPU0bit 1 对应 CPU1以此类推。两个位图文件内容和_list文件是一回事只是表达方式不同。用户态程序处理_list更省事内核内部处理位图更快。3. 源码走查topology.c 到底做了哪几件事3.1 属性组、可见性和初始化流程打开drivers/base/topology.c代码量不大核心结构是“一批属性宏 一个属性组 一个初始化函数”。属性宏的套路大概是这样的#define define_id_show_file(name) \ static ssize_t name##_show(struct device *dev, \ struct device_attribute *attr, \ char *buf) \ { \ return sysfs_emit(buf, %d\n, topology_##name(dev-id)); \ } \ static DEVICE_ATTR_RO(name)物理 package、die、core 这类单值属性都是靠这个宏生成的。dev-id在这里就是 CPU 编号topology_physical_package_id(cpu)这些函数负责去问架构层要具体值。然后定义属性组static struct attribute *topology_attrs[] { physical_package_id_attr.attr, die_id_attr.attr, core_id_attr.attr, thread_siblings_attr.attr, core_siblings_attr.attr, ... NULL, }; static umode_t topology_is_visible(struct kobject *kobj, struct attribute *attr, int i) { struct device *dev kobj_to_dev(kobj); if (attr die_id_attr.attr !topology_die_id(dev-id)) return 0; if (attr book_id_attr.attr !topology_book_id(dev-id)) return 0; ... return attr-mode; } static const struct attribute_group topology_attr_group { .attrs topology_attrs, .is_visible topology_is_visible, };初始化时遍历每一个可能的 CPU把属性组挂到对应的cpuX设备上static int __init topology_sysfs_init(void) { int cpu; for_each_possible_cpu(cpu) { struct device *dev get_cpu_device(cpu); if (dev) { if (sysfs_create_group(dev-kobj, topology_attr_group)) pr_warn(failed to register topology sysfs for cpu%d\n, cpu); } } return 0; } subsys_initcall(topology_sysfs_init);这里比较关键的一点是初始化用的是subsys_initcall而不是普通的module_init。拓扑信息在系统早期就可能有用户空间进程读取而且它不应该依赖某个设备驱动是否 probe 成功。即使属性挂载失败也只是打一条警告不让系统启动失败。这种“尽力而为”的初始化风格在系统级功能里很常见。3.2 topology_xxx 钩子背后的架构实现drivers/base/topology.c读的是topology_xxx(cpu)这类接口但真正实现可能藏在不同的地方。以 x86 为例arch/x86/kernel/topology.c很早就把 APIC ID 换算成 package ID、core ID存在cpuinfo_x86结构体里。topology_physical_package_id(cpu)最后会落到读取这个结构体对应字段。ARM64 那边的情况不太一样arch/arm64/kernel/topology.c负责从 MPIDR 寄存器解析亲和层级然后通过相同语义的topology_xxx钩子喂给通用层。s390 还会有 book、drawer 这样的额外层级所以在通用属性组里能看到这几个“罕见”属性但topology_is_visible会判断当前架构是否提供了非 0 值没有就直接隐藏避免每个 sysfs 目录里出现一堆无意义文件。这其实就是内核常见的“通用框架 架构钩子”模式。你在drivers/base/topology.c里看不到任何ifdef x86因为平台差异已经被接口盖住了。真要看懂一个属性的数值怎么来的不能只停在base目录还得跟着topology_xxx跳到具体架构源码里。我读这个文件最大的心得就是“属性名越通用背后依赖的架构细节越妖”。另外要特别注意sysfs 里这些文件是只读导出不是调度的配置开关。你往physical_package_id里 echo 数字会被拒绝因为DEVICE_ATTR_RO没有写方法。它对内核调度的真实影响是通过架构启动时填充的 cpu topology mask 进入调度域计算流程的sysfs 只是同一个数据面向用户空间的一个窗口。4. 实战用拓扑信息优化绑核和排查问题4.1 超线程、同核兄弟与“表面上很近实际上抢资源”拓扑信息最实在的用途是判断哪些 CPU 离得近、哪些 CPU 会抢同一组执行资源。看thread_siblings_list如果它是0,1说明 CPU0 和 CPU1 是同一个物理 core 上的两个逻辑处理器。它们共享 L1/L2 缓存也共享解码单元和大部分执行资源。意味着它们之间的线程切换延迟很低但两个重计算线程同时绑在 0 和 1 上吞吐未必比绑在 0 和 2 上高。反过来如果应用是延迟敏感的而且两个线程之间有大量共享数据要交换绑在同一对thread_siblings上又有好处因为共享缓存能帮忙减少了跨核同步开销。所以“绑核好不好”没有唯一答案得先说清楚是追求吞吐还是追求延迟再看拓扑信息做取舍。core_siblings_list则帮你划定了物理 package 的边界。同一个 package 内的不同物理 core共享的是更大的三级缓存和内存控制器路径跨 package 则要走到更远的互连总线。尤其在多路服务器上跨 socket 的缓存一致性流量是很贵的。4.2 写个小脚本快速画出 CPU 分布图我经常在排查问题时先跑一遍这个脚本把每颗 CPU 的 package 和 core 关系打出来#!/bin/bash for cpu in /sys/devices/system/cpu/cpu[0-9]*; do t$cpu/topology [ -d $t ] || continue echo ${cpu##*/} package$(cat $t/physical_package_id) core$(cat $t/core_id) threads$(cat $t/thread_siblings_list) done | sort -V输出大概是这样cpu0 package0 core0 threads0,1 cpu1 package0 core0 threads0,1 cpu2 package0 core1 threads2,3 cpu3 package0 core1 threads2,3 cpu4 package0 core2 threads4,5 cpu5 package0 core2 threads4,5 cpu6 package0 core3 threads6,7 cpu7 package0 core3 threads6,7再配合 NUMA 信息cat /sys/devices/system/node/node0/cpulist就能知道某个线程如果要从 CPU0 迁到 CPU7是不是跨了 NUMA 节点。像数据库、DPDK、音视频服务这类场景如果业务允许我通常会把一组常驻线程限制在同一个 NUMA 节点内避免每访问一块内存都要走远程路径。绑核用taskset就能做taskset -c 0,2 ./app更细的实时线程可以用pthread_setaffinity_np但前提是应用自己有设置亲和性的入口。不管用哪种方式第一步都是想清楚哪些 CPU 能作为一组依据就是thread_siblings_list、core_siblings_list、NUMA node 的cpulist。4.3 排查 CPU 数量对不上、拓扑信息异常实际工作中拓扑信息不对的场景我碰到过几种。一种是在虚拟机里。虚拟化平台给访客呈现的 CPU 拓扑不一定是真实的物理拓扑cpuX/topology/core_id甚至可能全部显示 0。这不一定是内核 bug可能只是 Hypervisor 用一颗物理核模拟出了多个 vCPU。做性能分析时不要拿虚拟机的core_siblings_list去推断宿主机真实 cache 拓扑。另一种是 BIOS/ACPI 的赋值问题。少数双路服务器会出现physical_package_id和实际 socket 数量对不上的情况或者core_id在某个 package 内不唯一。排查时先把dmesg里 CPU 拓扑相关的启动日志拉出来dmesg | grep -i smpboot\|topology\|cpu再看/proc/cpuinfo里的physical id、core id、siblings、cpu cores字段。如果 sysfs 和/proc/cpuinfo对不上大概率是启动阶段拓扑解析或 ACPI 表有问题需要往固件方向查而不是去改 sysfs。容器场景还有个容易踩的坑容器里直接挂载宿主机/sys看到的拓扑可能是整机的不是容器被 cpuset 限制后的拓扑。某些运行时会用 lxcfs 这类文件系统做重定向让容器内看到的 CPU 列表和 cgroup 限制一致。所以容器内做绑核之前先确认/sys/devices/system/cpu/online是否真的只包含允许使用的 CPU。现象可能原因排查方向thread_siblings_list只有单个 CPU超线程被关闭或架构不支持lscpu看Thread(s) per core所有core_id都为 0虚拟化拓扑不真实或平台未提供 core 信息对比宿主环境检查dmesgphysical_package_id大于实际 socket 数固件赋值不规范用dmidecode查物理槽位描述容器内发现 CPU 列表和整机一致/sys未经隔离用 lxcfs 或重新挂载隔离后的 sysfs这些坑大多不是内核代码报错而是“sysfs 只是信息投影不是物理事实”数据源在固件、架构解析和虚拟化层。拓扑文件本身就是一个中间产物。5. 学习时容易踩的坑与资料线索5.1 千万别把 sysfs 拓扑文件当成调度器拓扑看到“topology”这个词很容易顺手翻到内核里的kernel/sched/topology.c然后觉得两者是同一套东西。它们有关系但不是一个文件。kernel/sched/topology.c负责构造调度域scheduling domain根据 CPU 之间的共享关系建立层级用于负载均衡和任务迁移决策。它会读取架构提供的 CPU mask、cache 共享关系等数据再生成带标志位的调度域结构。而drivers/base/topology.c只是把同样来源的一部分拓扑信息用 sysfs 属性暴露给用户空间。最直接的迷惑发生在修改 sysfs 文件时如果尝试对thread_siblings做写操作会收到权限报错就算你通过特殊手段改了也不会改变调度器的行为。因为调度器看的是内部数据不是 sysfs 文件。学习的时候应该把这两者分开记台账驱动模型在这里负责“对外展示”调度器在这里负责“内部决策”。看代码的时候建议执行一次git log --oneline drivers/base/topology.c能看到这个文件随内核演进的变化一开始属性比较少后来补了 die、package 相关字段再后来调整了可见性判断逻辑。对照这个提交历史去理解“为什么现在有这些属性”比死记硬背字段列表更有用。5.2 建议按这个顺序读拓扑相关代码如果之前没接触过内核拓扑别一上来读drivers/base/topology.c。我建议的顺序是先看文档再看 sysfs 实测数据再看架构层实现最后回到base层看属性怎么挂。文档入口是内核里的Documentation/admin-guide/cputopology.rst内容不多但把每个属性都解释得很清楚。然后打开真机的/sys/devices/system/cpu/cpu0/topology/把core_id、physical_package_id、thread_siblings_list、core_siblings_list和lscpu -e对照一遍。有疑惑时再进arch/x86/kernel/topology.c或arch/arm64/kernel/topology.c找到对应钩子函数看目标值是启动时怎么算出来的。最后回到drivers/base/topology.c你会发现它本身几乎不藏逻辑真正值得琢磨的是“为什么架构层把某个数放在那个字段里”。工具方面hwloc里的lstopo值得一试它会把拓扑渲染成一张图cache、package、NUMA node 层级一目了然。图上看到某个 CPU 的位置再回 sysfs 找对应数据理解速度会快很多。不过要注意lstopo默认会合并很多表示细节和内核 sysfs 的原始字段不是一对一关系适合做宏观概览不适合作为唯一信息来源。我个人读这个文件最大的感受是topology.c本身平平无奇真正复杂的是它背后的架构差异。它像一张挂在墙上的地图地图不决定城市怎么建但你要在这片城市里调度车辆、规划路线时这张地图能帮你少走太多弯路。做性能优化前先扫一眼 CPU 拓扑再决定绑核和内存分配策略是我每次在新机器上部署服务时的固定动作。