Performance 如何在Linux(X86_64)中检查IRQ延迟以进行性能调整?

Performance 如何在Linux(X86_64)中检查IRQ延迟以进行性能调整?,performance,linux-kernel,x86-64,interrupt,cpu-architecture,Performance,Linux Kernel,X86 64,Interrupt,Cpu Architecture,有没有办法检查Linux内核中的中断处理延迟 或者有没有办法检查为什么在Linux 4.19.138的特定配置中CPU使用率只有40%呢 背景: 目前我遇到了一个问题,我的X86服务器运行第三方Linux-4.19.138内核(其配置文件约6000行)或Ubuntu 20.04 X86_64(其配置文件约9500行) 在这个服务器上运行netperf测试时,我发现第三方Linux-4.19.138内核的netperf的IO延迟比Ubuntu 20.04的还要差。运行第三方内核时CPU使用率低于

有没有办法检查Linux内核中的中断处理延迟

或者有没有办法检查为什么在Linux 4.19.138的特定配置中CPU使用率只有40%呢


背景:

目前我遇到了一个问题,我的X86服务器运行第三方Linux-4.19.138内核(其配置文件约6000行)或Ubuntu 20.04 X86_64(其配置文件约9500行)

在这个服务器上运行netperf测试时,我发现第三方Linux-4.19.138内核的netperf的IO延迟比Ubuntu 20.04的还要差。运行第三方内核时CPU使用率低于40%,而运行Ubuntu 20.04时CPU使用率约为100%

它们在内核运行时使用相同的内核命令行和相同的性能配置文件。
在Linux-4.19.138中,服务器中的中断或netserver进程似乎受到限制

然后,我使用短配置文件(6000行长)重建了Ubuntu20.04内核,并得到了类似的坏结果

因此得出的结论是内核配置造成了差异


在比较这两种配置(6000行与9500行)之前,为了缩小范围,我的问题是,有没有办法检查为什么在4.19.138的配置中CPU使用率只有40%呢?或者有没有办法检查Linux内核中的中断处理延迟?

我终于找到了原因。它来自
net.core.busy\u读取和
net.core.busy\u轮询均为0。
这意味着套接字轮询被禁用,这会影响netperf延迟

但问题变成了
在这种情况下,较低的CPU使用率表明Linux中存在一些不同之处,我们应该使用什么样的工具,或者如何找出导致两个内核CPU使用率差异的原因?

内核配置文件中的行数根本不能告诉我们哪些配置选项可能被设置为什么。较长的人可能会对一些需要回答更多问题的顶级选项说“是”,但这可能只是驱动因素。当你感兴趣的是两辆车在转弯时的表现如何时,这就像谈论两辆车的颜色一样有用。我不清楚你为什么要把CPU使用率和中断延迟纳入问题。Ubuntu可能正在使用更新的内核,并对服务器中的硬件提供更多支持(无论是优化还是技术)。顺便说一句,使用diff工具应该可以加快比较两个配置文件的速度。@Margaret Bloom很抱歉不清楚。让我澄清一下。首先,我们发现Linux-4.19.138比Ubuntu 20.04差。然后我们在Ubuntu 20.04中获得/构建/安装了正式的Linux-4.19.138。在那之后,我们只通过改变Ubuntu的4.19.138中的配置来检查测试结果,以确定哪一个是重要的。我们发现当CPU使用率为100%时,netperf延迟更好。如果CPU使用率为30-40%,则netperf延迟很差,因此我们重点关注如何提高CPU使用率。我找到了原因,让我分别回答这个问题