linux - 读取文件会杀死 NIC 中断

Question

我在使用基于 MIPS 处理器和 Linux 2.6 的主板时遇到了一个非常奇怪的问题。所有传入的以太网数据包都有 NIC 中断。如果我发送 10.000 个数据包，我可以看到发生了 10.000 个 NIC 中断。

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，U盘为32M NOR串口设备。为什么读取文件会终止 NIC 中断直到重启？

Answer 1

警告:这可能不是一个完整的解决方案，但我有一些想法。可能需要更多信息/测试。

当您 [系统] 什么都不做时，NIC 驱动程序快速足以响应中断并且 ISR 将完成对单个数据包的处理 < em>在下一个数据包到达之前。 (即)传入数据包和 NIC 中断之间存在一对一的关系。

如果您有其他系统事件，这可能会延迟进入 NIC 驱动程序的 ISR。此外，由于资源竞争(例如锁、kmalloc 等)，此其他事件可能会减慢 NIC 驱动程序中的处理速度

与此同时，更多 NIC 数据包 到达。当最终/最终进入 NIC ISR 时，它会看到有多个 数据包待处理。它将处理所有这些，不会离开 ISR。因此，它可能在每个中断上处理(例如)5 个数据包，因此中断计数减少了 5 倍。

这是大多数“智能”NIC 卡和驱动程序所做的。它实际上提高了繁重的 NIC 流量的吞吐量。通常，减少 NIC 中断是一件好事情，因为它减少了重复进入/退出 ISR 的浪费开销。

这实际上取决于数据包到达率和[平均]间隔。

因此，真正的问题是:“当中断次数减少时，您会丢失数据包/数据还是只看到性能损失？”

以及，您如何衡量系统性能差异？

有问题的文件系统是否以其他方式使用(例如，它是根文件系统)？或者，您的程序打开文件时是否仅访问 fs [而不是挂载它]

我不熟悉 jffs2 或您的闪存驱动程序，所以我想问您是否怀疑您正在做一些会长时间禁用中断的操作？

---

更新:

我刚刚注意到您使用的是 linux 2.6 版，该内核大约有 10 年的历史。它的生命周期已经结束，因此除非平台供应商提供驱动程序，否则它可能不会获得驱动程序错误修复。

因此，要考虑的另一件事是任何驱动程序都可能存在导致性能问题的错误。驱动程序很有可能已在更现代的内核中得到修复。

如果可以的话，您可能想切换到更新的内核。否则，您可能会面临将较新的驱动程序向后移植到较旧的内核的 [令人羡慕的] 任务 [或至少挑选一些错误修复]。