Stress-ng NUMA测试在无node0系统上的问题分析与解决

问题背景

在Linux系统性能测试工具stress-ng的使用过程中，我们发现当系统不存在NUMA node 0时，NUMA测试会失败。这是一个典型的硬件配置与软件假设不匹配导致的问题，值得我们深入分析。

问题现象

在特定硬件配置的系统上（NUMA节点编号从4开始，即节点4-7），执行stress-ng的NUMA测试时会出现以下错误：

stress-ng --numa 1 -t 60
stress-ng: fail: [29736] numa: mbind failed, errno=22 (Invalid argument)

错误信息表明mbind系统调用失败，返回EINVAL（无效参数）错误。通过numactl工具检查系统NUMA配置，确认系统确实没有node0，只有node4-7：

available: 4 nodes (4-7)
node 4 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
...

技术分析

NUMA架构基础

NUMA（非统一内存访问）是现代多处理器系统中的一种内存架构设计。在这种架构中，处理器访问本地内存比访问远程内存更快。Linux内核通过NUMA节点来管理这种架构，每个节点有自己的处理器和内存资源。

stress-ng NUMA测试原理

stress-ng的NUMA测试主要通过以下步骤工作：

1. 检测系统NUMA节点数量
2. 为每个NUMA节点分配内存区域
3. 使用mbind系统调用将内存绑定到特定NUMA节点
4. 对这些内存区域进行读写操作，测试NUMA性能

问题根源

在原始代码中，stress-ng假设NUMA节点编号从0开始连续分配。当系统配置特殊（如节点编号从4开始）时，代码尝试将内存绑定到不存在的node0，导致mbind调用失败。

解决方案

开发者通过以下方式解决了这个问题：

1. 使用NUMA节点位图代替固定节点编号
2. 动态检测可用的NUMA节点
3. 只对实际存在的NUMA节点进行操作

这种改进使得stress-ng能够适应各种NUMA节点编号配置的系统，提高了工具的兼容性。

验证结果

修复后的stress-ng在相同系统上成功运行NUMA测试：

stress-ng --numa 1 -t 60
stress-ng: info: [53391] numa: system has 4 of a maximum 256 memory NUMA nodes. Using 4.0MB mappings for each instance.
stress-ng: info: [53390] successful run completed in 1 min

技术启示

这个问题给我们以下启示：

1. 系统工具开发中不应假设硬件配置的连续性
2. 对于NUMA相关操作，应优先使用系统提供的动态检测接口
3. 错误处理应考虑各种可能的硬件配置场景
4. 系统调用失败时应提供有意义的错误信息

总结

stress-ng对NUMA节点编号的硬编码假设在特殊配置系统上导致测试失败。通过改用动态节点检测和位图管理，工具现在能够正确处理各种NUMA节点编号配置。这个问题展示了系统工具开发中考虑各种硬件配置的重要性，也为其他类似工具的开发提供了参考。