GPU内核态编程中的同步与并发控制实战

1. GPU内核态编程中的同步与并发挑战

在GPU内核态驱动开发中，同步与并发控制是保证系统稳定性的关键。不同于用户态程序，内核态环境下资源竞争和死锁问题会直接导致系统崩溃。以NVIDIA GPU为例，其内核驱动需要同时处理来自多个CUDA流的命令提交、显存管理中断服务等并行任务。我曾参与开发的一个深度学习推理框架就曾因为GPU驱动层的竞争条件导致整个节点卡死，最终通过重构同步机制才解决问题。

内核态环境有三个特殊约束：1)不能睡眠的原子上下文（如中断处理）；2)极高的性能要求（锁争用会显著降低吞吐量）；3)与硬件紧密耦合的操作时序要求。这决定了传统用户态的同步方案在内核态可能完全不适用。

2. 自旋锁在GPU驱动中的实战应用

2.1 自旋锁的适用场景分析

在GPU驱动中，自旋锁最适合保护短临界区。比如修改GPU寄存器状态时，以下代码展示了典型用法：

c复制spinlock_t reg_lock;
unsigned long flags;

void gpu_reg_write(uint32_t reg, uint32_t val) {
    spin_lock_irqsave(&reg_lock, flags);
    writel(val, gpu_base + reg);
    spin_unlock_irqrestore(&reg_lock, flags);
}

关键注意点：

1. 必须使用_irqsave变种防止中断重入
2. 锁内严禁调用可能睡眠的函数（如kmalloc）
3. 临界区执行时间应小于CPU调度时间片（通常<10μs）

2.2 调试自旋锁死锁的技巧

通过内核的lockdep子系统可以检测潜在死锁。在模块初始化时添加：

c复制#ifdef CONFIG_DEBUG_SPINLOCK
spin_lock_init(&reg_lock);
lockdep_set_class(&reg_lock, &gpu_lock_key);
#endif

当检测到锁顺序违规时，内核会打印警告信息。我曾遇到过一个真实案例：中断处理函数和普通路径反向获取两个锁，导致运行时随机死锁。通过lockdep提前发现了这个问题。

3. 信号量在长时操作中的使用范式

3.1 驱动初始化时的资源管理

GPU驱动加载时需要协调多个初始化步骤：

c复制DECLARE_MUTEX(init_sem);

int gpu_init() {
    if (!down_interruptible(&init_sem))
        return -EINTR;
    
    // 加载固件（可能睡眠）
    request_firmware(&fw, "gpu_fw.bin", device);
    
    up(&init_sem);
}

重要提示：在open()操作中使用信号量时，务必实现interruptible版本，否则会无法响应Ctrl+C终止操作。

3.2 用户态与内核态的同步边界

当需要将用户态请求序列化时，可以采用信号量+文件私有数据的模式：

c复制struct gpu_file_private {
    struct semaphore ioctl_sem;
};

static int gpu_open(struct inode *inode, struct file *filp) {
    struct gpu_file_private *priv = kmalloc(sizeof(*priv), GFP_KERNEL);
    sema_init(&priv->ioctl_sem, 1);
    filp->private_data = priv;
}

这样每个文件描述符拥有独立的同步上下文，避免不同进程间的相互阻塞。

4. 工作队列处理异步GPU事件

4.1 硬件中断与工作队列的配合

GPU中断处理需要遵循"top half/bottom half"原则：

c复制static DECLARE_WORK(gpu_irq_work, gpu_irq_work_fn);

irqreturn_t gpu_interrupt(int irq, void *dev_id) {
    uint32_t status = readl(GPU_STATUS_REG);
    
    if (status & IRQ_FAULT) {
        schedule_work(&gpu_irq_work);
        return IRQ_HANDLED;
    }
    return IRQ_NONE;
}

static void gpu_irq_work_fn(struct work_struct *work) {
    // 可以安全调用睡眠函数
    debug_dump_gpu_state();
    notify_userspace();
}

4.2 高并发工作队列优化

对于多核系统，需要使用工作队列池：

c复制static struct workqueue_struct *gpu_wq;

int gpu_init() {
    gpu_wq = alloc_workqueue("gpu_worker", WQ_UNBOUND | WQ_MEM_RECLAIM, 4);
}

void gpu_submit_work() {
    struct work_struct *work = kmalloc(sizeof(*work), GFP_KERNEL);
    INIT_WORK(work, process_gpu_cmd);
    queue_work(gpu_wq, work);
}

参数WQ_UNBOUND避免CPU缓存抖动，WQ_MEM_RECLAIM保证内存紧张时仍能处理关键任务。

5. 同步原语的性能对比实测

在AMD Radeon Pro W6800上测试不同同步方案的吞吐量（单位：万操作/秒）：

测试结果表明：纯计算任务中原子操作最快，但涉及硬件访问时必须使用锁。用户态交互场景中读写信号量表现最优。

6. 典型问题排查实录

6.1 自旋锁导致CPU 100%的问题

症状：单核CPU占用率持续100%，系统响应迟缓
排查步骤：

1. perf top显示该CPU一直在执行spin_lock代码
2. 检查锁持有者的调用栈（通过echo l > /proc/sysrq-trigger）
3. 发现某GPU中断处理函数在持有锁时触发了页错误

解决方案：将中断处理中的内存访问改为预分配，使用原子变量代替锁。

6.2 工作队列任务积压

症状：dmesg显示"workqueue jammed"警告
优化方法：

1. 改用多线程工作队列：alloc_workqueue(..., WQ_HIGHPRI | WQ_CPU_INTENSIVE, 0)
2. 实现任务优先级分级：

c复制struct gpu_work {
    struct work_struct work;
    int priority;
};

list_add_tail(&work->list, priority ? &hi_pri_list : &lo_pri_list);

7. 进阶同步模式实践

7.1 RCU在GPU驱动中的应用

对于频繁读、少量写的GPU状态监控，使用RCU比读写锁更高效：

c复制struct gpu_stats {
    unsigned long bytes_processed;
    struct rcu_head rcu;
};

void reader() {
    struct gpu_stats *stats;
    rcu_read_lock();
    stats = rcu_dereference(current_stats);
    printk("%lu bytes", stats->bytes_processed);
    rcu_read_unlock();
}

void updater() {
    struct gpu_stats *new = kmalloc(...);
    // 更新new状态
    rcu_assign_pointer(current_stats, new);
    synchronize_rcu();
    kfree(old); 
}

7.2 基于DMA_FENCE的GPU流水线同步

现代GPU驱动使用dma_fence协调跨引擎依赖：

c复制struct dma_fence *fence1 = gpu_submit_work(batch1);
struct dma_fence *fence2 = gpu_submit_work(batch2);

struct dma_fence *dep_fences[] = { fence1, fence2 };
struct dma_fence *combined = dma_fence_unwrap_merge(dep_fences, 2);

gpu_submit_work_with_dependency(batch3, combined);

这种机制被Vulkan和CUDA等API底层广泛使用，实现了高效的硬件级同步。