该文章展示了一张关于Q6 sqpoll的CPU采样热力图，用于分析io_uring中sqpoll模式下的CPU使用分布情况。
正文
根据提供的文章内容，主要信息如下：这是一张关于Q6 sqpoll所有CPU样本的热力图。标题为“https://frn.sh/iouring/q6-sqpoll-all.svg”，来源网址为“https://frn.sh/io-uring/”，发布时间为2026年9月1日21:45:09（GMT）。页面提示这是原始页面的缓存快照，建议在需要时尝试使用缓存退出选项重新获取。
评论
根据评论内容，主要观点和论据总结如下：
观点一：iouring 与 preadv 的对比 - 评论1（marginalianu）认为，在用户空间进行连续预读时，使用 preadv 更优，因为它能限制预读到下一个驻留页面，且在 Marginalia 索引的实验中，preadv 在所有可用单次调用完成完整读取的场景下都优于 iouring。 - 关键引用："If you're doing contiguous readahead in userspace, why not just use preadv?" 和 "preadv beats iouring in all cases you can use a single preadv call to do the full read."
观点二：iouring 与 ODIRECT 的选择 - 评论2（amluto）质疑为何选择在系统调用和 iouring 加 ODIRECT 之间做取舍，指出 Turso 类似 SQLite 支持多进程访问同一数据库，缓冲在某些工作负载下是巨大优势，并询问 iouring 不加 ODIRECT 或使用 RWFDONTCACHE 的中间方案有何问题。 - 关键引用："What’s wrong with iouring without direct?" 和 "There’s also the middle ground of RWF_DONTCACHE."
观点三：基准测试的局限性 - 评论4（ComputerGuru）强调，基准测试（如 TPC）不适合确定正确方法，因为嵌入式数据库通常运行在共享资源的机器上，需权衡性能与 CPU/内存使用。将缓存从内核接管（如 ODIRECT）会带来全局资源管理问题，类似 ZFS 在 FreeBSD 中的缓存分离问题。 - 关键引用："Benchmarking... is NOT the way to determine the correct approach here" 和 "This isn’t even iouring specific and I’m hardly the first to bring this up in the context of O_DIRECT."
其他评论 - 评论3（weatherlite）询问 iouring 是否使用黄色线程（可能为笔误或幽默表达），未获直接回应。 - 评论5（ErroneousBosh）将标题误读为“Iouring without Radiohead”，并调侃其无意义。