每条命令只有不到一微秒
NVMe 规范允许最多 65535 对 SQ/CQ，但一块盘实际能用满多少队列，取决于主控内部有几条彼此独立的命令处理流水线。CORE 7 系列的 J750 与 J770 走 PCIe 4.0 x4 链路，4KB 随机读的规划目标是 1,500 KIOPS，平均下来每条命令的端到端处理预算不足 0.7 µs。在这个尺度上，任何跨核共享的资源——一把 FTL 映射表的锁、一段被多核轮询的完成队列内存——都会直接变成吞吐天花板，而不是可以留到后期调优的细节。
三个真正的开销点
第一个是 doorbell。主机每提交一批命令都要写一次 doorbell 寄存器，高 IOPS 下这些 MMIO 写会占用上行事务，固件侧必须按批读取 SQ 条目而不是逐条响应。第二个是映射表访问的局部性，随机负载的 LBA 分布决定映射页命中率，绑核策略若把相邻 LBA 分散到不同核，缓存局部性就被打散。第三个是完成路径：中断聚合能显著降低主机 CPU 的中断次数，但每一次聚合都在等待窗口里累加延迟。
QD1 延迟与高队列深度吞吐的对立
J750/J770 规划的 QD1 平均延迟指标是读 65 µs、写 10 µs，写侧的数字来自掉电保护支撑下的回写缓存。这组数字只有在聚合窗口接近关闭时才成立。工程上不追求单一配置通吃：元数据与日志这类延迟敏感负载用极短窗口，而顺序读 7,400 MB/s、顺序写 5,500 MB/s 的带宽型负载允许更激进的聚合。固件把两种模式做成运行时可切换的 QoS 档位，而不是编译期常量。
当前验证状态
调度相关测试跑在内部工程平台 JH-E4U-C 上，两款产品仍处于产品定义/EVT 阶段，上面这些数字都是规划目标而非实测承诺。当前重点是把队列数、绑核方式与聚合窗口三者做成正交的可配置项，使不同服务器平台上的实测结果能够直接回灌到默认参数表，而不必每次改动固件重新编译。