0

我对基于 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，闪存驱动器是 32M NOR 串行设备。为什么读取文件会杀死 NIC 中断，直到重新启动？

4

1 回答 1

2

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

当您 [系统不做] 任何其他操作时，NIC 驱动程序的速度足以响应中断，并且 ISR 将在下一个数据包到达之前完成对单个数据包的处理。(ie) 传入的数据包和 NIC 中断之间存在一对一的关系。

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

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

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

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

所以，真正的问题是：“当中断计数减少时，你会丢失数据包/数据还是仅仅看到性能损失？”

而且，您如何衡量系统性能差异？

有问题的文件系统是否以其他方式使用（例如它是根 fs）？或者，您的程序是打开文件的唯一访问 fs [除了挂载它]

我不熟悉jffs2或你的闪存驱动程序，所以我想问你是否怀疑做一些会在很长一段时间内禁用中断的事情？

更新：

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

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

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

于 2016-10-08T23:05:48.010 回答