上篇 Event 机制全景—从 Doorbell 到 Signal 介绍了 Event 的定位、九种类型、三层架构和 Signal Page 概念以及 event 的全生命周期时序。在理解了前文的基础上，来到我们本篇的主线：GPU 完成任务后如何高效通知 CPU？这个问题面临三重约束或者说三个需求：低延迟（不能让 CPU 空等）低开销（不能每次都陷入内核）可扩展（支持数千 event 的批量等待）。本篇围绕内核如何通过五个关键设计决策解决这些矛盾展开。1. Signal Page：轮询与中断的折中设计问题：纯中断通知延迟低但开销大（每次 signal 都要 trap 进内核）；纯轮询零开销但浪费 CPU。如何两全？答案：Signal Page——一块 CPU/GPU 共享内存，每个 signal event 占一个 64-bit slot。┌─────────────────────────────────────────────────────────┐ │ 5.2 event 内核实现 — KFD Event 的低延迟、低开销、可扩展技术
上篇 Event 机制全景—从 Doorbell 到 Signal 介绍了 Event 的定位、九种类型、三层架构和 Signal Page 概念以及 event 的全生命周期时序。在理解了前文的基础上，来到我们本篇的主线：GPU 完成任务后如何高效通知 CPU？这个问题面临三重约束或者说三个需求：低延迟（不能让 CPU 空等）低开销（不能每次都陷入内核）可扩展（支持数千 event 的批量等待）。本篇围绕内核如何通过五个关键设计决策解决这些矛盾展开。1. Signal Page：轮询与中断的折中设计问题：纯中断通知延迟低但开销大（每次 signal 都要 trap 进内核）；纯轮询零开销但浪费 CPU。如何两全？答案：Signal Page——一块 CPU/GPU 共享内存，每个 signal event 占一个 64-bit slot。┌─────────────────────────────────────────────────────────┐ │