探索与解决：Intel E810网卡的4ms单并发IO延迟问题

主要观点总结

本文探讨了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延迟的问题。

正文

请到「今天看啥」查看全文

具体来说，这个APIC定时器的频率较低，通常在1000Hz以下，而当前出问题的Host为250Hz，因此每4ms调度一次，这与IO延迟4ms是相吻合的。然而，这个频率是在内核编译时确定的，修改起来并不容易，且直觉上问题不太可能出在这里。毕竟，为了解决这个问题，不可能将频率改为100万Hz。那么，为什么IO会在 smp_apic_timer_interrupt 的调度流程中完成呢？IO真正的完成应该是在什么流程中呢？

继续探究IO未及时处理的原因

继续使用Ftrace跟踪更多详细的信息。

在 ib_cq_completion_softirq 的下一个函数调用是 __raise_softirq_irqoff 。翻阅内核源码后，发现 irq_poll_sched 这个函数至关重要。它负责调度软中断处理，并与IO完成的路径密切相关。进一步分析 irq_poll_sched 的调用时机和作用，可能揭示出为何IO在软中断处理链中被延迟触发。

这意味着， irq_poll_sched 函数并不希望在当前流程中立即处理I/O，而是将当前I/O加入到CPU的延迟任务处理队列中，等待延迟处理。然而，实际情况是处理延迟了4ms，这个延迟确实过长了。注意这一行代码： __raise_softirq_irqoff(IRQ_POLL_SOFTIRQ); 。 __raise_softirq_irqoff() 触发了指定类型的软中断，这里是 IRQ_POLL_SOFTIRQ ，用于调度一个软中断处理函数来处理加入轮询队列 的I/O任务。

请到「今天看啥」查看全文