实战踩坑记：在AMD GPU驱动中调试GEM对象泄漏（附工具与排查思路）

黑日终

209人浏览 · 2026-06-14 11:05:05

黑日终 · 2026-06-14 11:05:05 发布

AMD GPU驱动调试实战：GEM对象泄漏排查全指南

当你在深夜调试GPU驱动时，突然发现系统显存逐渐耗尽，性能急剧下降——这很可能是遇到了GEM对象泄漏问题。作为驱动开发者，我们需要一套系统化的排查方法，而不是盲目地四处查找。本文将分享一套经过实战检验的GEM泄漏排查流程，从工具使用到代码分析，帮你快速定位问题根源。

1. 问题现象与初步诊断

典型的GEM泄漏场景往往表现为以下几种症状：

系统运行一段时间后出现显存不足错误（-ENOMEM）
nvidia-smi 或 radeontop 显示显存占用持续增长但无对应活跃进程
系统日志中出现 drm 子系统的内存分配失败警告
图形应用崩溃后相关资源未完全释放

第一步确认泄漏存在 ：使用简单的压力测试脚本循环创建销毁OpenGL上下文，同时监控显存变化：

#!/bin/bash
while true; do
    glxgears >/dev/null 2>&1 &
    sleep 1
    killall glxgears
    sleep 1
    nvidia-smi --query-gpu=memory.used --format=csv | tail -1
done

如果显存占用呈现阶梯式增长而非稳定波动，基本可以确认存在泄漏。

2. 关键调试工具链配置

现代Linux DRM子系统提供了丰富的调试接口，需要先确保内核配置正确：

配置选项	推荐设置	作用说明
CONFIG_DEBUG_FS	y	启用debugfs文件系统支持
CONFIG_DRM_DEBUG_MM	y	启用DRM内存管理调试
CONFIG_DRM_AMD_DC_DCN	y	AMD显示核心调试支持
CONFIG_LOCKDEP	y	锁依赖关系检测

加载AMDGPU驱动时启用调试模式：

modprobe amdgpu debug=0x1

这会启用基本的内存分配跟踪功能。更详细的调试级别：

0x1：基本调试信息
0x2：内存管理详细日志
0x4：硬件异常调试
0x8：原子操作检查

提示：生产环境慎用高级别调试，可能影响性能

3. GEM对象状态检测实战

3.1 使用drm_info工具检查

drm_info 是现代DRM调试的瑞士军刀，安装方法：

git clone https://gitlab.freedesktop.org/emersion/drm_info
meson build && ninja -C build install

查看GEM对象统计：

drm_info -G

关键输出字段解析：

handle ：GEM对象的唯一标识符
size ：对象占用字节数
name ：关联的驱动程序内部名称
flags ：内存区域标志（VRAM/SYSTEM等）
refcount ：引用计数（泄漏重点检查项）

3.2 debugfs接口深度利用

DRM在/sys/kernel/debug/dri/下为每个GPU卡创建调试目录，常用检查点：

# 列出所有GEM对象
cat /sys/kernel/debug/dri/0/amdgpu_gem_objects

# 显示TTM内存池状态
cat /sys/kernel/debug/dri/0/amdgpu_vram_mm

特别有用的TTM迁移状态检查：

watch -n 1 'cat /sys/kernel/debug/dri/0/amdgpu_migrate_status'

3.3 动态ftrace跟踪

对于间歇性泄漏，静态检查可能不够，需要动态跟踪：

echo 1 > /sys/kernel/debug/tracing/events/amdgpu/enable
echo 1 > /sys/kernel/debug/tracing/tracing_on
# 重现问题场景...
cat /sys/kernel/debug/tracing/trace_pipe | grep gem_

重点关注以下事件：

amdgpu_gem_object_create
amdgpu_gem_object_free
ttm_bo_validate

4. 常见泄漏模式与修复方案

根据AMD驱动维护者的经验，GEM泄漏主要有以下几种模式：

4.1 引用计数失衡

典型症状： drm_info 显示对象的refcount始终大于0。常见于：

错误处理路径中未释放引用
跨模块引用传递时计数错误
回调函数中未正确处理释放

修复示例：

// 错误示例
void foo(struct drm_gem_object *obj) {
    drm_gem_object_get(obj); // 增加引用
    if (error) {
        return; // 泄漏点！
    }
    drm_gem_object_put(obj);
}

// 正确写法
void foo(struct drm_gem_object *obj) {
    drm_gem_object_get(obj);
    if (error) {
        drm_gem_object_put(obj); // 确保释放
        return;
    }
    drm_gem_object_put(obj);
}

4.2 TTM迁移残留

当BO在VRAM和系统内存间迁移失败时，可能留下残留对象。检查方法：

dmesg | grep -i "ttm migration failed"

关键修复点：

验证 ttm_bo_validate 返回值
确保迁移失败后的清理路径
检查 ttm_tt 对象的销毁逻辑

4.3 进程退出未清理

用户空间进程崩溃时，驱动需要正确处理资源回收。检查驱动是否实现了：

static const struct file_operations amdgpu_fops = {
    .release = amdgpu_release, // 必须实现
    ...
};

在release回调中需要：

遍历所有GEM对象
检查孤儿对象（owner为已死进程）
执行强制释放

5. 高级调试技巧

5.1 自定义debugfs节点

对于复杂问题，可以添加临时调试节点：

static int gem_leak_show(struct seq_file *m, void *data) {
    struct amdgpu_device *adev = m->private;
    list_for_each_entry(bo, &adev->gem.objects, list) {
        if (kref_read(&bo->kref) > 1) {
            seq_printf(m, "Leak suspect: handle=%u, size=%zu, ref=%d\n",
                      bo->handle, bo->size, kref_read(&bo->kref));
        }
    }
    return 0;
}
DEFINE_SHOW_ATTRIBUTE(gem_leak);

注册到debugfs：

debugfs_create_file("gem_leak", 0444, adev->ddev->primary->debugfs_root,
                    adev, &gem_leak_fops);

5.2 内存压力测试

使用专用工具模拟极端情况：

# 创建内存压力
stress-ng --vm-bytes $(awk '/MemAvailable/{printf "%d\n", $2 * 0.9;}' /proc/meminfo)k --vm-keep -m 1

# 同时运行GPU负载
glmark2 --run-forever

观察在内存压力下TTM迁移行为是否正常。

5.3 内核内存分析器

对于复杂泄漏，可以使用 kmemleak ：

echo scan > /sys/kernel/debug/kmemleak
cat /sys/kernel/debug/kmemleak | grep amdgpu_gem

需要内核配置 CONFIG_DEBUG_KMEMLEAK=y 。

6. 预防性编程实践

根据Linux DRM维护者的经验，以下实践能显著减少GEM泄漏：

引用计数审计 ：所有 get/put 调用必须成对出现
错误路径测试 ：强制触发各错误分支验证资源释放
自动化回归测试 ：将内存检查集成到CI流程
生命周期文档 ：为每个GEM对象绘制状态转换图

示例检查脚本：

#!/bin/bash
# 内存泄漏回归测试
BASE=$(drm_info -G | awk '{sum += $2} END {print sum}')
./run_gpu_test
AFTER=$(drm_info -G | awk '{sum += $2} END {print sum}')
if [ $AFTER -gt $BASE ]; then
    echo "Test failed: memory leak detected"
    exit 1
fi

在AMDGPU驱动代码库中，这些实践已被证明能将内存泄漏减少90%以上。