- 如何估计ARM处理器上的irq延迟
- irq延迟的定义是什么
-
中断请求（irq）延迟是指中断请求从中断源传输到服务点所需的时间。
-
因为有不同的中断通过不同的路径来自不同的源，所以它们的延迟显然取决于中断的类型。您可以在ARM站点上找到关于特定中断的延迟（包括值和原因）的非常好的解释表
您可以在ARM9E-S核心技术参考手册：中找到更多信息
4.3最大中断延迟
如果采样信号在多周期指令启动的同时被断言它的第二个或更晚的执行周期，中断异常条目直到指令已完成
最长的LDM指令是加载所有寄存器的指令，包括PC。
将第一个执行周期计算为1，LDM需要16个周期。
•LDM要传输的最后一个字在循环17中传输，中止在该循环中返回传输的状态。
•如果发生数据中止，处理器在周期18中检测到，并准备循环19中的数据中止异常条目。
•周期20和21是数据中止条目的获取和解码阶段分别地
•在周期22期间，处理器准备FIQ条目，发出Fetch and Decode循环23和24中的循环。
•因此，FIQ例程中的第一条指令进入第25阶段的管道，给出24个周期的最坏情况延迟。
和
最小中断延迟
FIQ或IRQ的最小延迟是可以对请求进行采样的最短时间通过输入寄存器（一个周期）加上异常进入时间（三个周期）。第一个中断指令在中断后四个周期进入执行流水线阶段断言
中断延迟有三个部分：
- 中断控制器自己获取中断。现代处理器往往能很快做到这一点，但在设备发出引脚信号和中断控制器接收引脚信号之间仍有一段时间——即使只有1ns，也是时间[或发出中断信号的任何方法]
- 处理器开始执行中断代码之前的时间
- 应该处理中断的实际代码运行之前的时间，也就是说，在处理器确定了哪个中断，以及驱动程序代码或类似代码的哪一部分应该处理中断之后
通常情况下，操作系统不会对1产生任何影响。操作系统肯定会影响2。例如操作系统有时会禁用中断[以避免中断干扰某些关键操作，例如修改与中断处理有关的内容，或安排新任务时，甚至在中断处理程序中执行时。一些操作系统可能会禁用中断数毫秒，而一个好的实时操作系统禁用中断的时间最多不会超过微秒
当然，从中断处理程序中的第一条指令运行到实际的驱动程序代码或类似程序运行所需的时间可能是相当多的指令，操作系统负责所有这些指令。
对于实时行为，这通常是"最坏的情况"，在非实时操作系统中，总体执行时间要重要得多，因此，如果几百条指令不启用中断更快，因为它保存了几个"启用中断，然后禁用中断"的指令，Linux或Windows类型的操作系统很可能会选择这样做。
Mats和Nemanja提供了一些关于中断延迟的好信息。有两个是Mats给出的三个问题之外的另一个问题。
- 其他同时/近乎同时的中断
- 由于屏蔽中断而增加的操作系统延迟编辑：这是Mats的答案，只是没有解释太多
如果单个内核正在处理中断，那么当多个中断同时发生时，通常会有一定的解决优先级。但是，中断处理程序中通常会禁用中断，除非启用优先级中断处理。因此，例如，慢速NAND闪存IRQ被发信号并运行，然后发生以太网中断，它可能被延迟，直到NAND闪存IRQ完成。当然，如果您有优先级中断，并且您担心NAND闪存中断，那么如果以太网被赋予优先级，情况实际上可能会更糟。
第二个问题是当主线代码清除/设置中断标志时。通常，这是用这样的东西来完成的
mrs r9, cpsr
biceq r9, r9, #PSR_I_BIT
检查Linux源代码中的arch/arm/include/asm/irqflags.h，了解主线代码使用的许多宏。一个典型的序列是这样的，
lock interrupts;
manipulate some flag in struct;
unlock interrupts;
如果struct导致页面故障，则可能会引入非常大的中断延迟。在页面故障处理程序的持续时间内，中断将被屏蔽。
Cortex-A9有很多无锁指令，可以通过从不屏蔽中断来防止这种情况；因为汇编指令比CCD_ 2更好。第二个问题与ldm/stm类型指令导致的IRQ延迟非常相似（这些只是运行时间最长的指令）。
最后，许多技术讨论将假定零等待状态RAM。很可能需要填充缓存，如果您知道内存数据速率（可能是2-4个机器周期），那么最坏情况下的代码路径将乘以此。
是否有SMP中断处理、优先级中断和无锁主线取决于内核配置和版本；这些都是操作系统的问题。其他问题是CPU/SOC中断控制器和中断代码本身固有的。