CUDA P2P D2D cudaMemcpyAsync与核函数执行序列化问题排查求助

问题背景回顾 #

单节点双H100 NVL GPU，两进程各绑定一块GPU，通过CUDA IPC跨进程访问Peer内存。计算流（compute_stream）依次执行Kernel0、Kernel1、Kernel2，拷贝流（copy_stream）在Kernel0运行期间提交P2P cudaMemcpyAsync。存在Kernel2时，拷贝需等待Kernel1完成后才启动；移除Kernel2则拷贝与计算正常重叠。

问题1：独立流上的P2P D2D cudaMemcpyAsync被隐式延迟的触发条件 #

结合你的场景，可能的触发条件包括以下几种：

1. 内存访问的隐式依赖约束
   如果P2P拷贝的源/目标内存区域被后续计算流中的任务（比如你的Kernel2）写入，CUDA驱动会自动插入隐式同步，保证拷贝操作读取到的是最终的内存数据（而非中间态）。即使两个流是独立的，驱动会基于内存依赖关系强制序列化任务——这种情况在跨进程IPC内存场景下会更严格，因为跨进程的内存一致性无法通过进程内的流依赖机制轻易保证。
2. 核函数的全局内存访问模式与缓存行为
   你的Kernel2是用户实现的归约核函数，这类核函数通常会对连续的全局内存区域进行密集读写，且可能触发大量的缓存写回操作。当GPU的内存子系统（包括L2缓存、NVLink链路缓冲区）被这类任务占满时，DMA引擎的P2P拷贝请求会被延迟，直到内存子系统释放足够资源——这解释了为什么移除Kernel2后拷贝能正常重叠。
3. 跨进程IPC内存的页表同步开销
   当通过IPC访问跨进程内存时，GPU的页表可能需要在两个进程间同步状态。如果计算流中的任务（比如Kernel2）频繁修改该内存区域的访问属性或触发页表更新，驱动会延迟拷贝操作，直到页表状态稳定，避免出现非法访问或数据不一致。

问题2：跨进程IPC访问时P2P拷贝的已知约束/序列化行为 #

是的，跨进程CUDA IPC场景下的P2P拷贝存在一些特殊约束，即使流独立也可能触发序列化：

• 跨进程内存一致性强制同步：与进程内P2P拷贝不同，跨进程的内存访问没有共享的进程内内存上下文，驱动会对涉及IPC内存的读写操作施加更严格的一致性检查。如果一个进程的计算流正在写入IPC内存区域，另一个进程的拷贝流读取该区域时，驱动会隐式等待所有写入操作完成，确保数据一致性。
• IPC句柄的访问权限锁定：当计算流中的任务正在使用IPC内存（比如Kernel2持续读写），驱动会锁定该IPC句柄的访问权限，禁止DMA引擎的拷贝操作并行执行，直到计算任务释放该内存的访问锁。
• NVLink链路的跨进程调度优先级：H100 NVL的NVLink链路在处理跨进程P2P请求时，调度优先级可能低于进程内的计算任务。当计算流的任务（尤其是像Kernel2这类高内存占用的核函数）占满NVLink链路的带宽或缓冲区时，跨进程拷贝请求会被排队等待，直到计算任务完成。

验证建议 #

• 检查Kernel2是否与P2P拷贝的源/目标内存存在重叠访问：通过cudaMemsetAsync标记内存区域，或使用Nsight Compute追踪内存访问范围，确认是否存在内存依赖。
• 修改Kernel2的内存访问模式：尝试使用局部内存减少全局内存访问压力，或调整归约的粒度，观察拷贝延迟是否消失。
• 显式添加流间依赖：如果确实需要保证拷贝读取Kernel2的结果，可通过cudaStreamWaitEvent显式建立拷贝流与计算流的依赖；如果不需要，可调整内存区域，避免拷贝与Kernel2访问同一内存。

内容的提问来源于stack exchange，提问作者Abhishek Ghosh