Stress-ng项目在ARM64架构下的af-alg压力测试问题分析与解决

问题背景

Stress-ng是一个强大的系统压力测试工具，其中的af-alg模块用于测试Linux内核的加密算法接口。近期在ARM64架构的ThunderX Cavium硬件上运行该测试时，发现了一个异常现象：测试无法正常终止，部分子进程会变成僵尸进程。这一问题在Ubuntu Bionic（5.4内核）和Focal（5.15内核）的HWE版本中均有出现，但在虚拟化环境中却无法复现。

问题现象

当在ARM64裸金属服务器上执行以下命令时：

./stress-ng -v -t 5 --af-alg 4 --af-alg-ops 3000 --ignite-cpu --syslog --verbose --verify --oomable

测试会出现以下异常表现：

1. 部分子进程变为僵尸状态（Z+）
2. 父进程卡在wait4系统调用
3. 系统日志中仅显示"NET: Registered protocol family 38"信息
4. 无法通过Ctrl+C终止测试

技术分析

通过strace跟踪发现，异常进程停留在SIGALRM信号处理循环中。进一步分析表明：

1. 原子锁问题：问题首次出现在引入ARM架构yield指令的提交中，这表明与ARM架构的原子操作实现有关。

2. NUMA架构影响：问题仅在ARM64 NUMA系统上出现，而在虚拟化环境（非NUMA）中正常，暗示问题与缓存一致性相关。

3. 内核交互：测试过程中触发了内核加密子系统，但未产生明显的错误日志，表明问题可能发生在用户空间与内核空间的交互边界。

解决方案演进

开发团队尝试了多种解决方案：

1. 初始修复：移除ARM特定的yield指令，回退到通用的shim_sched_yield。

2. 强制终止机制：添加5秒超时强制终止逻辑，虽然能防止挂起，但产生了大量"JMP out"消息，不是理想方案。

3. 最终方案：完全禁用ARM架构的原子自旋锁，回退到更稳定的pthread自旋锁实现。这一修改在多个内核版本（5.4、5.15、6.8、6.10）上验证有效。

技术深度解析

ARM架构（特别是NUMA系统）的原子操作实现有其特殊性：

1. 内存一致性模型：ARM采用弱一致性内存模型，需要显式的内存屏障指令保证多核间的数据可见性。

2. 缓存一致性：NUMA系统中，跨节点的缓存同步可能引入额外延迟，影响自旋锁的性能和正确性。

3. 指令重排序：ARM处理器允许更多的指令重排序，需要谨慎处理同步原语。

这些特性使得在ARM架构上实现高效的原子操作比x86架构更具挑战性。Stress-ng最终选择放弃针对ARM的优化实现，转而使用更稳定但性能稍逊的pthread锁，这是权衡正确性与性能后的合理选择。

实际影响与价值

这一问题的解决不仅修复了Stress-ng工具本身的问题，还带来了额外价值：

1. 硬件兼容性提升：增强了工具在ARM服务器级硬件上的可靠性。

2. 内核问题发现：在测试过程中意外发现了Linux内核加密子系统的潜在问题（LP: #2067527），展示了压力测试工具的价值。

3. 架构差异认知：提醒开发者在不同架构上实现同步原语时需要特别注意内存模型和缓存一致性问题。

最佳实践建议

基于这一案例，我们建议：

1. 在ARM服务器上进行压力测试时，关注NUMA架构带来的特殊影响。

2. 对于关键的系统调用测试，建议结合strace和内核日志进行综合分析。

3. 在跨架构开发时，同步原语的实现需要针对不同架构进行充分验证。

Stress-ng团队对这一问题的快速响应和解决方案展示了开源社区解决复杂系统问题的能力，也为ARM服务器生态的稳定性做出了贡献。