Linux io_uring 為什麼仍可能卡住？從固定 Buffer 到 Completion Queue 的 I/O 路徑 / Why Linux io_uring Can Still Stall: Fixed Buffers and Completion Queues
現象：io_uring 非同步，為什麼服務仍會卡住？ / Symptom: Why can an io_uring service still stall? 你把大量檔案讀取改成 Linux io_uring，CPU 使用率下降，卻仍看到請求延遲突然拉高。提交請求變得非同步，不代表儲存裝置立刻完成；queue depth、檔案系統與 block I/O 仍會把等待時間留在 completion 之前。 You moved file reads to Linux io_uring, CPU usage fell, yet request latency still spikes. Submission becomes asynchronous; storage, the filesystem, and block I/O can still delay completion. io_uring 的基本路徑是：應用程式準備 submission queue entry（SQE），核心取出並執行，最後把結果寫成 completion queue entry（CQE）。共享 ring 減少系統呼叫，但 CQE 的 res 才是實際結果；不能只看到 SQE 已提交，就把工作算成完成。 The path is: the application prepares an SQE, the kernel executes it, and a CQE reports the result. Shared rings reduce syscall traffic, but CQE res is the real outcome. Submission is not completion. 圖一｜io_uring 的 SQE→核心執行→CQE 路徑；固定 buffer 的生命週期與完成延遲必須分開觀察。 / Figure 1 | The SQE-to-kernel-to-CQE path; buffer lifetime and completion latency are separate signals. Original conceptual diagram. 機制：固定 Buffer 解決什麼，又帶來什麼責任？ / Mechanism: what registered bu...