Linux内核在arm cortex A9上处理中断需要多少条指令？

Question

我希望估计一个ARM cortex A9单核处理器处理IRQ所需的操作码数量。

假设我使用Linux内核3.4，调用irq并执行irq_handler需要多少操作码？

- 0x90

---

为什么需要操作码？您是指指令还是时钟周期？ - Turbo J

@0x90 “操作码”（operation code）指的是二进制代码，用于编码特定的操作，以便CPU知道要执行哪个操作。指令是操作码加上编码参数的其他位，例如。 - Étienne

嗨，你成功做到了吗？我也在解决类似的问题，并尝试建模当裸机应用程序在ARM Cortex A9 CPU上运行时的最坏情况。非常感谢任何指针。 - Nuetrino

我会在完成我的项目后在这里添加结果。 - Nuetrino

@0x90 您确定瓶颈是控制器吗？因为根据ARM的文档所述，在理论知识方面，控制器中的延迟似乎可以被限制（2-3个gclks，即clk的1/4）？您能否分享一下您是如何得出这个结论的？不过我还没有进行实现。顺便说一句，我假设您在谈论ARM-Cortex A9中的pl190中断控制器。 - Nuetrino

Answer 1

您的问题涉及如何计算Linux的中断延迟。至少您可能对在中断开始之前需要多长时间感兴趣。我们将忽略此处的irqs方面。

一种简单的方法是切换GPIO并使用示波器测量中断。您甚至可以多次切换GPIO，以查看不同阶段所需的时间。此Window CE链接显示了测量延迟的示例。某些中断控制器（例如IMX）具有I/O多路复用模式，其中中断号将提高/降低特定的I/O线。或者，您可以添加代码以切换该行（有关例程，请参见下文）。

主要中断处理的源代码在entry-armv.S中。您使用的中断控制器有定义的宏，这些宏取决于.config文件。例如，有抢占中断、多中断控制器、SMP等。 主要向量在entry-armv.S底部定义。一般来说，当前操作模式会被检查，然后选择__irq_usr或__irq_svc。这些例程有不同的前导内容用于存储状态，但它们最终都会调用irq_handler宏。_irq_usr有关于cmpxchg的内容，但如果您在.config中指定了ARM cortex，则不适用。主要区别将是在用户模式下发生IRQ后可能进行的上下文切换。您的机器定义了mach/entry-macro.S，这是用于访问中断控制器并获取中断号的汇编宏。然后跳转到顶级内核目录中的通用irqhandling code。

所以第二种方法是检查代码并直接计算。如果您查看源代码，编译内核，然后在vmlinux图像上执行objdump --disassemble，并查找这些符号，这可能更容易，并且查看irq_handler宏扩展，最终应该跳转到您的IRQ代码。

从源代码中可以看出，还有TRACE_IRQFLAGS。您可以使用make menuconfig（并键入/TRACE_IRQFLAGS）检查您正在使用的Cortex A9是否可用。我不知道它是否可用。

还有一些变化。

1. 来自用户/SVC模式的中断。
2. 当前正在运行其他中断。
3. 被中断的代码（例如stm/ldm）可能需要一些时间才能完成。
4. 在您的ISR中出现页面故障。一些Alsa驱动程序在至少某些Linux版本中可能会使用未分配的页面导致错误。
5. 在您的ISR中使用条件语句。

使用示波器测量将显示IRQ服务中的抖动。检查指令通常会显示IRQ可能永远不会得到服务；例如，如果更高优先级的中断不断地抢占/防止IRQ。可能您需要同时执行这两个操作以完全针对硬截止日期进行优化。

通常，您不关心整个IRQ需要多长时间，而是关心IRQ线被引发和写入/读取某些外围寄存器之间的时间。例如，一个FIFO可能具有有限的深度，如果发生IRQ并且读取FIFO寄存器之间的延迟大于FIFO_Size x BPS，则FIFO就会溢出。

FIQ基础设施速度更快，但可用的内核设施要少得多！

编辑：Cortex A9 技术参考手册在附录B中列出了指令计数。在大多数体系结构上，大多数ARM指令只需一个周期，除了内存读/写、乘法和分支指令。按照上面第3和第4段的步骤找到处理Linux中断的完整指令路径，并将它们相加；对于一个估计值（因为原问题要求），您可以直接计算指令数，因为它们通常只需要一个周期。

- artless noise

Answer 2

虽然您可以通过检查源代码计算核心周期的理论最小值，但由于缓存、内存和内存控制器性能、另一个核心正在执行的任务以及取决于ARM处理器的微体系结构等各种因素的影响，实际的核心周期数量则不确定得多。

我怀疑您最好使用数字“范围表”或性能计数器来测量系统的实际中断延迟性能。

当然，对于硬实时应用程序，您需要知道最坏情况下的中断延迟-这包括所有这些因素的最坏情况。

- marko

---

你能否详细解释一下如何从源代码理论上测量最坏情况？谢谢。 - 0x90

我认为没有其他方法可以做到这一点，除非对整个CPU和内存子系统进行准确的寄存器级模拟（例如使用Verilog或VHDL设计）-并且需要一个工作负载在其上运行，以便您可以模拟设备中各种缓存的影响。同样，我认为您必须进行测量并做出一些假设。 - marko

你肯定可以大致限制它。如果你能限制行星上的粒子数量，我认为你可以限制ARM CPU在最好和最坏情况下的工作方式。 - 0x90

绝对没错 - 差别可能只是偶尔的缓存未命中和一些内存延迟。我猜我们在看十分之一微秒的范围。Linux内核本身会产生更多的延迟。难点在于基于系统参考手册和原理图估算这些影响。 - marko

最坏情况是所有缓存未命中，不是吗？ - artless noise