我对基于MIPS处理器和Linux 2.6的主板有一个非常奇怪的问题。所有传入的以太网数据包都有网卡中断。如果我发送10000个数据包，我可以看到发生了10000个网卡中断。
START SYSTEM
SEND 10k PACKETS
/mnt/system # cat /proc/interrupts
CPU0
24: 10000 MIPS NIC
29: 7192 MIPS timer
30: 0 MIPS UART1
31: 3092 MIPS serial
ERR: 0
但是，在打开和关闭文件系统中的一个文件（用零或正则填充）之后，生成的NIC中断要少得多。例如，对于10k数据包，只有2-7k个中断。这会对系统性能产生不利影响，但在重启所有具有NIC中断的设备后，一切都会恢复正常。
START SYSTEM
std::fstream f;
f.open("/mnt/system/myfile");
f.close();
WAIT FOR SOME TIME
SEND 10k PACKETS
/mnt/system # cat /proc/interrupts
CPU0
24: 2045 MIPS NIC
29: 7192 MIPS timer
30: 0 MIPS UART1
31: 3092 MIPS serial
ERR: 0
文件系统是jffs2，闪存驱动器是32M或串行设备。
为什么读取文件会在重新启动前终止NIC中断？
最佳答案
警告：这可能不是一个完全的解决方案，但我有一些想法。可能需要更多信息/测试。
当你做[系统做]其他事情时，网卡驱动程序足够快来响应中断，ISR将在下一个包到达之前完成对单个包的处理。（即）传入数据包和NIC中断之间存在一对一的关系。
如果您有其他系统活动，这可能会延迟进入NIC驱动程序的ISR。此外，由于资源竞争（例如锁，kmalloc等），此其他活动可能会减慢NIC驱动程序中的处理速度
与此同时，更多的网卡数据包到达。最后/最终输入NIC ISR时，它会看到有多个数据包挂起。它将处理所有这些，而不离开ISR。因此，它可能在每个中断上处理（例如）5个包，因此中断计数减少了5倍。
这是大多数“智能”网卡和驱动程序所做的。它实际上通过大量的NIC流量提高了吞吐量。通常，较少的NIC中断是一件好事，因为它减少了重复输入/退出ISR的浪费开销。
这实际上取决于包到达率和[平均]间隔。
所以，真正的问题是：“当中断计数减少时，您是丢失数据包/数据还是仅仅看到性能损失？”
那么，您是如何衡量系统性能差异的呢？
有问题的文件系统是否以其他方式使用（例如，它是根文件系统）？或者，您的程序打开文件是对fs的唯一访问吗[而不是安装它]
我不熟悉jffs2或你的flash驱动程序，所以我想问你是否怀疑有人做了什么会使中断失效很长一段时间的事情？
更新：
我注意到你使用Linux版本2.6内核大约10岁。它已经过了生命的尽头，所以除非平台供应商提供，否则它很可能无法修复驱动程序的错误。
所以，另一件要考虑的事情是，任何驱动程序都可能有导致性能问题的错误。很有可能这些驱动程序已经安装在更现代的内核中。
如果可以的话，您可能需要切换到一个新的内核。如果没有，你可能会被留下来[不可行的]任务，将新的驱动程序反向移植到旧的内核[或者至少选择一些错误修复程序]。
关于linux - 读取文件会杀死NIC中断，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/39936956/