主要观点总结
本文探讨了zStorage分布式块存储系统在特定环境下使用FIO工具测试时出现的IO延迟问题，通过对问题的定界和深入分析，最终找到了问题所在并提供了解决方案。
关键观点总结
关键观点1: 问题现象和背景
近期，zStorage系统在海光+麒麟+E810网卡环境下使用FIO工具测试4K单并发随机读/写IO时，延迟达到4ms，而使用Mellanox网卡时延迟正常。
关键观点2: 问题定界
通过时延分析、更换HOST、Ftrace跟踪分析等手段，确定问题可能与内核有关。
关键观点3: 4ms延迟流程深究
根据Ftrace信息，发现4ms的延迟出现在Host端的内核处理上，与APIC定时器和软中断处理机制有关。
关键观点4: 解决策略
通过分析IO处理流程，确定问题出在__raise_softirq_irqoff函数上，提出使用不带下划线的raise_softirq_irqoff或Tasklet来触发延迟任务作为解决方案。
关键观点5: 实验结果
使用Tasklet触发延迟任务后，时延降低至130us，解决了4ms延迟的问题。
文章预览
注：本文内容引用自张洋老师的知乎文章 https://zhuanlan.zhihu.com/p/735757082，他 是一位存储研发专家。 问题现象和背景 近期，zStorage分布式块存储系统在海光+麒麟 +E810网卡环境下，使用FIO工具测试4K单并发随机读/写IO时，延迟达到4ms。而这里唯一的变量是E810网卡；如果采用Mellanox网卡，在同样的测试用例下，IO延迟约为100us左右。那么问题出在网卡吗？还是另有原因？以下是分析和探索的过程分享。 问题定界 要分析上述高时延问题，首先需要对问题进行定界：是zStorage存储软件的问题，还是Host端的问题？针对这一问题，我们做了以下几件事情： - 时延分析 ：zStorage FrontEnd从收到IO到应答IO给Host，耗时 < 100us，符合预期。这个实验表明问题大概率不在存储端，但仍不能完全断定问题在Host端。 - 更换HOST：重新使用一个内核版本为5.10的系统，进行相同的
………………………………
