OpenBLAS多线程测试中的内存限制问题分析与解决

问题背景

在OpenBSD 7.6系统上使用OpenBLAS-0.3.29版本时，用户遇到了一个奇怪的现象：当线程数超过10时，openblas_utest测试程序会无限期挂起。具体表现为单个CPU核心被完全占用，但测试无法继续进行。这个问题不仅影响测试过程，还会在使用依赖OpenBLAS的Python科学计算库(如scipy)时导致整个Python内核挂起。

现象分析

通过详细测试，用户发现：

• 当设置OPENBLAS_NUM_THREADS=1到10时，测试能在毫秒级完成
• 当线程数设置为11时，测试会在执行到potrf:bug_695时挂起
• 线程数超过11时，程序会直接挂起且无任何输出
• 系统具有20个硬件核心，但问题与是否启用SMT(同步多线程)无关

深入调查

使用调试工具lldb进行分析后，发现程序在内存分配环节出现了问题。具体调用栈显示：

1. 程序在memory.c文件的alloc_mmap函数中挂起
2. 调用链为：blas_memory_alloc → adjust_thread_buffers → blas_thread_init → gotoblas_init
3. 核心问题出现在内存映射(mmap)系统调用处

根本原因

通过检查系统资源限制，发现问题的根源在于OpenBSD默认的数据段大小限制(ulimit -d)设置不足。具体表现为：

• 默认数据段限制为1572864 KB(约1.5GB)
• OpenBLAS在多线程模式下需要更多内存空间来分配线程缓冲区
• 当线程数超过10时，内存需求超过了默认限制
• 程序在尝试分配更多内存时被阻塞，导致挂起现象

解决方案

解决这个问题的方法很简单：适当提高数据段大小的系统限制。用户可以通过以下命令解决：

ulimit -d SOME_LARGE_NUMBER

在实际操作中，将SOME_LARGE_NUMBER设置为一个足够大的值(如unlimited)后，测试程序能够顺利完成，所有线程配置下的测试都能正常通过。

经验总结

1. 资源限制检查：在遇到类似的多线程程序挂起问题时，应首先检查系统资源限制(ulimit)，特别是内存相关限制

2. 测试环境配置：对于高性能计算库的测试，需要确保测试环境有足够的系统资源

3. 调试技巧：使用调试工具(lldb/gdb)分析挂起点的调用栈，可以快速定位问题根源

4. 跨平台差异：不同操作系统对资源管理的默认配置可能不同，在OpenBSD等BSD系系统上需要特别注意

这个问题虽然最终解决方案简单，但排查过程展示了系统资源限制对高性能计算库的重要影响，也为类似问题的解决提供了参考思路。