name: Bug Report
about: libvgpu v2.10 下 conda torch 2.1.2 的 import torch 死锁
labels: kind/bug
发生了什么:
conda 版 pytorch 2.1.2(MKL 2021/2022 线)在 HAMi v2.10.0 注入环境下,import torch 即死锁:OpenMP runtime 探测与 libvgpu 被拦截的 dlsym 相互影响,进程单线程 100% CPU 空转(strace -p 5 秒无系统调用,wchan=0)、无任何输出、服务端口不监听,直到被外部杀掉。
CPU 版 torch 同样触发(与 CUDA 无关);官方 pytorch/pytorch:2.1.2-cuda12.1-cudnn8-runtime 镜像(MKL 构建不同)不触发;同一 pod 在 v2.9.0 下正常。
期望行为:
import torch 正常完成(v2.9.0 下可以)。
如何复现:
- 在带 NVIDIA GPU 的集群安装 HAMi v2.10.0。
- 创建如下 pod:
apiVersion: v1
kind: Pod
metadata:
name: hami-210-repro
spec:
schedulerName: hami-scheduler
containers:
- name: repro
image: continuumio/miniconda3
command: ["sh","-c"]
args:
- |
conda config --add channels https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud/pytorch/
conda config --add channels https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud/conda-forge/
conda install -y python=3.10 pytorch==2.1.2 cpuonly libgomp
timeout 25 python -c "import sys; print('s1',flush=True); import torch; print('torch-ok',flush=True)"
echo "EXIT=$?"
resources:
limits:
nvidia.com/gpu: 1
requests:
nvidia.com/gpu: 1
- 结果:打印
s1 后不打印 torch-ok,进程空转至 timeout 杀掉(EXIT=124)。单进程即可触发,无需 fork。
补充说明:
对比 libvgpu 子模块 v2.9(5091a2f)与 v2.10(b216ba1)的差异,有两处改动值得关注:
-
src/libvgpu.c 中 dlsym(RTLD_NEXT) 的递归保护被移除(v2.9 有 dlmap/check_dlmap,递归时返回 NULL;v2.10 直接转发)。MKL 的 OpenMP 探测若重入该 hook,可能造成用户态自旋——与观察到的现象(100% CPU、无 syscall、卡在 torch/_C dlopen 帧、maps 中有 libmkl_core/libomp)相符,但尚需进一步确认。
-
lock_postinit()(src/multiprocess/multiprocess_memory_limit.c):v2.9 为带超时降级的信号量;v2.10 改为 fcntl 文件锁 + for(;;) 无限重试(无超时),并新增 pthread_atfork 重置。本次挂死可能与此无关(自旋无 syscall),但作为潜在死锁点建议一并评估。
相关 issue:#1834(libvgpu 首次 CUDA 调用挂死,症状相似)、#2641(libvgpu 下 vLLM NCCL 初始化挂起,仅有 workaround)、#723(recursive dlsym 后挂死,2024 年报告,与本次 dlsym 问题同源)、#1662(libvgpu 并发初始化锁竞争,v2.10 锁重写即为此性能问题的修复)。
环境:
- HAMi 版本:v2.10.0(异常)vs v2.9.0(正常)
- Kubernetes 版本:v1.32.13
- 加速卡:NVIDIA L20 48GB(A100-SXM4-80GB 上同样复现)
- 资源:
nvidia.com/gpu 整卡分配
- 驱动/运行时:610.57.04;nvidia-container-toolkit;containerd 2.3.3
- 操作系统:Ubuntu 24.04.2 LTS,内核 6.8.0-138
name: Bug Report
about: libvgpu v2.10 下 conda torch 2.1.2 的 import torch 死锁
labels: kind/bug
发生了什么:
conda 版 pytorch 2.1.2(MKL 2021/2022 线)在 HAMi v2.10.0 注入环境下,
import torch即死锁:OpenMP runtime 探测与 libvgpu 被拦截的dlsym相互影响,进程单线程 100% CPU 空转(strace -p5 秒无系统调用,wchan=0)、无任何输出、服务端口不监听,直到被外部杀掉。CPU 版 torch 同样触发(与 CUDA 无关);官方
pytorch/pytorch:2.1.2-cuda12.1-cudnn8-runtime镜像(MKL 构建不同)不触发;同一 pod 在 v2.9.0 下正常。期望行为:
import torch正常完成(v2.9.0 下可以)。如何复现:
s1后不打印torch-ok,进程空转至 timeout 杀掉(EXIT=124)。单进程即可触发,无需 fork。补充说明:
对比 libvgpu 子模块 v2.9(
5091a2f)与 v2.10(b216ba1)的差异,有两处改动值得关注:src/libvgpu.c中dlsym(RTLD_NEXT)的递归保护被移除(v2.9 有dlmap/check_dlmap,递归时返回 NULL;v2.10 直接转发)。MKL 的 OpenMP 探测若重入该 hook,可能造成用户态自旋——与观察到的现象(100% CPU、无 syscall、卡在torch/_Cdlopen 帧、maps 中有libmkl_core/libomp)相符,但尚需进一步确认。lock_postinit()(src/multiprocess/multiprocess_memory_limit.c):v2.9 为带超时降级的信号量;v2.10 改为 fcntl 文件锁 +for(;;)无限重试(无超时),并新增pthread_atfork重置。本次挂死可能与此无关(自旋无 syscall),但作为潜在死锁点建议一并评估。相关 issue:#1834(libvgpu 首次 CUDA 调用挂死,症状相似)、#2641(libvgpu 下 vLLM NCCL 初始化挂起,仅有 workaround)、#723(recursive dlsym 后挂死,2024 年报告,与本次 dlsym 问题同源)、#1662(libvgpu 并发初始化锁竞争,v2.10 锁重写即为此性能问题的修复)。
环境:
nvidia.com/gpu整卡分配