ROCm HIP Graph 概念与机制分析-第 3 章 数据结构：辅助资源管理

本章目标第 2 章讲的是图长什么样这一章讲图跑起来要靠哪些幕后资源。GraphExec之所以能在重放时做到近乎零 CPU 开销靠的是三个预分配的资源管理器——kernel 参数池、HW 信号池、用户对象——以及一套贯穿全子系统的静态注册表 有效性检查防御模式。理解它们才能真正读懂后面实例化时准备好一切、执行时直接复用的调度章节。3.1 为什么需要资源池回顾第 1 章的总纲——空间换时间。重放一张图时每个 kernel 节点都需要两样东西一块kernel 参数内存kernarg把实参打包好给 GPU 读。一个或多个完成信号HW signal / event让运行时知道这一步什么时候在 GPU 上做完。如果每次Run()都临时malloc参数内存、临时createSignal那 CPU 端开销一点没省——又回到了裸 launch 的老路。所以GraphExec的思路是在Init()实例化时一次性把这些资源池建好重放时只从池子里借、用完还永不在热路径上创建。这三样幕后资源分别由三个类管理类管理什么基类关键手法GraphKernelArgManagerkernel 参数内存池amd::ReferenceCountedObjectamd::GraphKernelArgManager分块chunk bump 指针分配GraphSignalManagerHW 完成信号集合池amd::ReferenceCountedObject预建 N 组信号借/还复用UserObject用户对象生命周期amd::ReferenceCountedObject引用计数 析构回调三者都继承amd::ReferenceCountedObject——因为它们可能被多个持有者GraphExec、子图、多个流共享用引用计数来决定何时真正释放。3.2 GraphKernelArgManagerkernel 参数内存池先看类定义节选classGraphKernelArgManager:publicamd::ReferenceCountedObject,publicamd::GraphKernelArgManager{public://! 为给定大小在 device 上分配一整块 kernarg 池boolAllocGraphKernargPool(size_t pool_size,amd::Device*device);//! 从当前 chunk 按 size/alignment 切一小块 kernel 参数//! 当前 chunk 用满就再分配一整块新 chunkaddressAllocKernArg(size_t size,size_t alignment,intdevId)override;//! HDP flush若 flush 寄存器无效则回退到 readbackvoidReadBackOrFlush();private:structKernelArgPoolGraph{address kernarg_pool_addr_;//! 池基址size_t kernarg_pool_size_;//! 池大小size_t kernarg_pool_offset_;//! 当前分配偏移};booldevice_kernarg_pool_false;//! 参数池是否在设备内存std::unordered_mapamd::Device*,std::vectorKernelArgPoolGraphkernarg_graph_;//! 每设备一组已分配的 kernarg 池};它的核心是一个经典的arena / bump-pointer 分配器够不够AllocKernArgsize/align当前 chunk够放吗?对齐 offset返回地址offset sizeAllocGraphKernargPool再要一整块 chunkkernarg_graph_是Device → vectorchunk每个设备一串已分配的大块chunk。多设备场景下互不干扰。AllocKernArg只是移动偏移量在当前 chunk 里把kernarg_pool_offset_按alignment对齐切出size字节返回然后把 offset 往后推。这是 O(1) 且无锁竞争的极快分配。满了才向底层要新块只有当前 chunk 装不下时才调用AllocGraphKernargPool一次性申请一大块新 chunk。也就是说底层昂贵的显存/主机内存分配被摊薄到极少数次。析构统一归还~GraphKernelArgManager遍历kernarg_graph_把每个 chunk 用hostFree整块释放——不是逐个小分配释放而是整块回收干净利落。~GraphKernelArgManager(){for(autokernarg:kernarg_graph_){for(autoelement:kernarg.second){kernarg.first-hostFree(element.kernarg_pool_addr_,element.kernarg_pool_size_);}kernarg.second.clear();}}ReadBackOrFlush()与内存一致性kernarg 可能位于设备可见内存CPU 写完参数后需要确保 GPU 能看到最新值。它优先走HDP flush硬件的一致性刷新路径当 flush 寄存器不可用时回退到readback读一下强制同步。这属于 GPU 内存一致性的细节知道写完参数要 flush 一下让 GPU 看见即可。一句话GraphKernelArgManager把每个 kernel 一次 malloc变成了整张图共享几大块内部 bump 指针切分这是参数内存层面的空间换时间。3.3 GraphSignalManagerHW 信号集合池第二个资源是完成信号。类定义清清楚楚写明了设计意图//! Per-GraphExec pool of HW event sets.classGraphSignalManager:publicamd::ReferenceCountedObject{public://! 在实例化时预建 num_sets 组、每组 count 个信号//! 这样 launch 永远不必在热路径上创建信号boolPrepopulate(amd::Device*device,intcount,intnum_sets);//! 为一次 launch 借一组就绪信号从空闲池弹出//! 只有池意外为空时才兜底新建一组boolAcquireSet(amd::Device*device,intcount,std::vectorvoid*out_set);//! 归还一组用过的信号并重新 arm放回空闲池。//! 由 launch 完成回调调用——此时保证该 launch 的 GPU 工作已结束voidReleaseSet(amd::Device*device,std::vectorvoid*set);private:std::mutex lock_;//! 每设备一叠空闲信号集std::unordered_mapamd::Device*,std::vectorstd::vectorvoid*free_sets_;};它是一个标准的对象池Object Pool工作节奏是借—用—还三拍AcquireSet 借GPU 完成回调ReleaseSet 还Prepopulate实例化时预建 N 组free_sets_空闲池一次 launch使用信号集关键设计点Prepopulate在Init()阶段调用一次性建好num_sets组信号每组count个。之后热路径上的 launch 只借不建。AcquireSet优先从空闲池弹出注释里明确说only creates a new set as a fallback if the pool is unexpectedly empty——正常情况下永远命中池子兜底才新建。这保证了绝大多数重放的信号获取是 O(1) 且零系统调用。ReleaseSet由完成回调触发注意归还的时机——launch 完成回调。为什么非要等回调因为只有 GPU 真正执行完这一批信号才空闲下来、可以安全地re-arm重新装填再借给下一次 launch。这是一个并发正确性的要点信号的复用严格由 GPU 完成事件驱动lock_保护free_sets_的并发存取。为什么叫集合set而非单个信号一次图 launch 内部可能有多段/多流需要一组信号同时协作第 6、7 章的分段与同步计划会用到所以池子的最小借还单位是一组信号。GraphSignalManager把每次执行 create/destroy 一堆信号变成了实例化时建好、循环里借还复用是同步原语层面的空间换时间。它和第 7 章的SyncPlan、以及 launch 完成回调OnLaunchComplete是一条线上的伙伴。3.4 UserObject引用计数与生命周期第三个类和性能关系不大管的是用户对象的生命周期——用户通过hipUserObjectCreate往图上挂一个带析构回调的对象比如一块需要在图销毁时释放的资源交给运行时托管。classUserObject:publicamd::ReferenceCountedObject{typedefvoid(*UserCallbackDestructor)(void*data);public://! 哪些 Graph 拥有这个 user objectstd::unordered_setGraph*owning_graphs_;UserObject(UserCallbackDestructor callback,void*data,unsignedintflags):ReferenceCountedObject(),callback_(callback),data_(data),flags_(flags){amd::ScopedLocklock(UserObjectLock_);ObjectSet_.insert(this);// 构造即登记}virtual~UserObject(){amd::ScopedLocklock(UserObjectLock_);if(callback_!nullptr){callback_(data_);// 析构时回调用户释放函数}ObjectSet_.erase(this);// 从注册表移除owning_graphs_.clear();}voidincreaseRefCount(constunsignedintrefCount){for(uint32_ti0;irefCount;i)retain();}voiddecreaseRefCount(constunsignedintrefCount){assert((refCountreferenceCount())count is bigger than refcount);for(uint32_ti0;irefCount;i)release();}// ...private:UserCallbackDestructor callback_;void*data_;unsignedintflags_;staticstd::unordered_setUserObject*ObjectSet_;staticamd::Monitor UserObjectLock_;};几个要点引用计数即生命周期UserObject继承amd::ReferenceCountedObject用retain()/release()计数。HIP 的 user object API 允许一次增减多个引用于是有了increaseRefCount/decreaseRefCount这种批量 retain/release的封装。当计数归零对象析构。析构回调析构时若callback_非空就调用它并把data_传回去——这正是用户注册的东西没人用了就这么释放的钩子。这让运行时能安全托管任意用户资源。owning_graphs_记录归属一个 user object 可以被多张图引用。注释点明了一个易错点——当对象即将被删除最后一次release()时必须把指向它的指针从各个 Graph 的 user object 列表里清掉否则又是悬垂指针。ObjectSet_isUserObjvalid和节点一样构造登记、析构注销配一个静态有效性检查——这就引出了本章最后、也是最重要的一个横切模式。3.5 横切模式静态注册表 有效性检查到这里你应该已经在四个不同的类里看到了同一套代码骨架类注册表有效性检查锁GraphNodenodeSet_isNodeValidnodeSetLock_GraphgraphSet_isGraphValid对应 set 锁GraphExecgraphExecSet_isGraphExecValidgraphExecSetLock_UserObjectObjectSet_isUserObjvalidUserObjectLock_它们的模板完全一致// 1) 一个静态集合登记所有活着的对象staticstd::unordered_setT*XxxSet_;staticamd::Monitor XxxLock_;// 或 recursive_mutex / shared_mutex// 2) 构造时登记T(...){amd::ScopedLocklock(XxxLock_);XxxSet_.insert(this);}// 3) 析构时注销~T(){amd::ScopedLocklock(XxxLock_);XxxSet_.erase(this);}// 4) 静态有效性检查句柄是否还活着staticboolisXxxValid(T*p){amd::ScopedLocklock(XxxLock_);returnp!nullptrXxxSet_.find(p)!XxxSet_.end();}这个模式解决什么问题HIP 是 C 风格 API用户拿到的是不透明句柄hipGraph_t、hipGraphNode_t、hipGraphExec_t、hipUserObject_t本质就是裸指针。用户完全可能传一个已经销毁的句柄use-after-free传一个根本不是该类型的野指针在多线程里一边销毁一边使用。如果运行时直接解引用就是崩溃或更隐蔽的内存破坏。静态注册表把这个指针是不是我发出去的、现在还活着吗变成了一次 O(1) 的哈希查找把非法句柄挡在 API 边界之外。这是一道纯粹的防御性安全网对应 OWASP 里不受信任输入校验的思路只不过这里的不受信任输入是 API 句柄。代价与权衡每次对象构造/析构都要抢一次全局锁、动一次全局集合——有一定开销但相对于图的创建/销毁频率远低于重放频率完全可接受。注册表是进程级全局的所以配套的锁不能少GraphExec甚至用到recursive_mutex和shared_mutex读多写少时用共享锁来降低竞争。它只能保证指针曾经是一个有效对象且尚未析构不能防住指针被 realloc 复用到同地址这种极端 ABA但在实践中足够可靠。一句话记住这个模式凡是会以裸指针句柄暴露给用户的类都用静态 set 登记 isXxxValid 查表来做悬垂/非法句柄防护。第 2 章的nodeSet_、本章的三个资源类都是它的实例。3.6 三类资源在生命周期中的位置把本章三个资源管理器放回第 1 章的生命周期时间轴上能看得更清楚它们各自的活跃区间销毁 Destroy重放 Run 循环实例化 Init下一次借GraphKernelArgManager建 kernarg 大块GraphSignalManagerPrepopulate 预建信号组AllocKernArgbump 切参数AcquireSet借信号组GPU 完成回调ReleaseSet 还信号~GraphKernelArgManager整块 hostFreeUserObject 析构回调释放用户资源参数池Init()建块 → 每次Run()bump 切分 →Destroy整块归还。信号池Init()预建 → 每次Run()借 → GPU 完成回调还 → 循环复用。用户对象贯穿始终由引用计数决定寿命归零时触发析构回调释放用户资源。这三条线正是第 57 章调度执行零成本重放的物质基础——调度算法再巧也得有现成的参数内存和信号可用。3.7 本章小结GraphExec的高性能重放建立在三个预分配资源管理器之上全部继承amd::ReferenceCountedObject以支持共享与引用计数生命周期。GraphKernelArgManager是bump-pointer arena按设备维护若干大块 chunkAllocKernArg只移动偏移量满了才要新块析构整块回收ReadBackOrFlush处理写后一致性。GraphSignalManager是对象池Prepopulate实例化时预建信号组AcquireSet借、ReleaseSet由 GPU 完成回调还严格由完成事件驱动复用lock_保护并发。UserObject用引用计数 析构回调托管用户资源owning_graphs_记录归属最后一次 release 时须清理各图的引用。贯穿全子系统的横切模式是静态注册表 isXxxValidnodeSet_/graphSet_/graphExecSet_/ObjectSet_把非法/悬垂句柄挡在 API 边界外是一道 O(1) 的防御性安全网。下一章进入生命周期构建与实例化我们会看两种建图方式手动 API vs 流捕获、ihipGraphAddNode如何落地一次带依赖的加节点以及GraphExec::Init()究竟在实例化阶段预计算了哪些东西、如何预分配 stream——把本章的资源池真正点燃。