我在寻找可以帮助估计x86 cpu上中断延迟的信息。这篇非常有用的论文可以在"datasheets.chipdb.org/Intel/x86/386/technote/2153.pdf"上找到。但是这篇论文给我提出了一个非常重要的问题:如何定义当前指令完成等待所带来的延迟?我的意思是在识别INTR信号和执行INTR微码之间的延迟。我记得，英特尔软件开发人员手册中也提到了当前正在执行的指令等待完成的情况。但它也说明了一些事情，一些指令可以在过程中被中断。主要问题是:如何为特定的处理器定义最大完成指令等待长度。需要以核心节拍和内存访问操作为单位进行评估，而不是以秒或微秒为单位。应该考虑缓存和TLD缺失，以及其他可能影响等待的东西。
这个估计是研究实现不影响中断延迟的小临界段的可能性所必需的。为了达到这个目的，临界区的长度必须小于或等于CPU最长不可中断指令的长度。
我们非常欢迎任何形式的帮助。如果你知道一些有帮助的论文，请分享链接。
如果agner fog的优化手册(辅以英特尔开发人员手册)没有任何内容，则不太可能有人/任何其他内容(除了一些内部英特尔/amd数据):http://www.agner.org/optimize/
通常，中断延迟没有保证的上限。考虑下面的例子:
- 通过执行
sti指令禁用可屏蔽中断，该指令设置IF标志。 - 处理器通过执行
hlt指令转换到C1休眠状态。 - 发生可屏蔽中断，其亲和性指定它只能在该处理器上处理。
在这种情况下，处理器将不会处理中断，直到不可屏蔽中断发生唤醒处理器，并且IF标志被清除以允许处理可屏蔽中断。
如果所有处理中断的处理器都处于深度睡眠状态，任何中断(包括不可屏蔽中断)的中断延迟可能在数百微秒左右。在我的Haswell处理器上，C7状态的唤醒延迟是133次。如果这对您来说是一个问题，您可以使用Linux内核参数intel_idle.max_cstate(在使用intel_idle驱动程序的情况下，这是英特尔处理器上的默认设置)或processor.max_cstate(用于acpi_idle驱动程序)来限制最深的c状态。您可以使用idle=poll告诉内核永远不要让任何核心进入睡眠状态，这可以最大限度地减少空闲核心上的中断延迟，当然前提是频率不会因为热调节而降低。使用轮询循环还会降低所有核心的最大turbo频率，这可能会降低系统的整体性能。
在活动核(状态C0)上，只有当核处于可中断状态时才接受硬件中断。这种状态发生在指令边界，字符串指令除外，因为字符串指令是可中断的。Intel并没有提供在一个暂挂中断被接受之前可以退役的指令数的上限。合理的实现可能会停止向ROB(在指令边界处)发出uops，并等到ROB中的所有uops退役后，才开始执行用于调用中断处理程序的微码例程。在这样的实现中，中断延迟取决于退役所有挂起的up所花费的时间。高延迟指令，如负载、复杂浮点运算和锁定指令，很容易使中断延迟达到数百纳秒的量级。但是，如果其中一个挂起的uops由于某种原因(或某些特定原因)需要微码辅助，处理器可能会选择刷新该指令和所有后续指令，而不是调用辅助。这种实现以增加中断延迟为代价提高了性能和功耗。
在另一个为最小化中断延迟而调整的实现中，所有正在运行的指令都立即刷新，而不会退出任何内容。但是，当中断处理程序返回时，所有这些通过管道的刷新指令和其中一些可能已经完成的指令都需要被取出并再次通过管道。这将导致性能下降和功耗增加。
硬件中断会耗尽Intel和AMD x86处理器上的存储缓冲区和写合并缓冲区。参见:在汇编指令运行时中断它。来自Intel的一篇题为"通过使用消息信号中断来减少中断延迟"的论文讨论了一种测量PCIe设备中断延迟的方法。本文使用术语"中断延迟"来表示与您提到的论文中的"中断响应时间"相同的东西。您需要在中断到达处理器时以某种方式获取时间戳，然后在中断处理程序的开始处获取另一个时间戳。中断延迟的近似值可以通过两者相减来计算。问题当然是获取第一个时间戳(也是以与第二个时间戳相当的方式)。英特尔的论文建议使用一个PCIe分析器，它由一个PCIe设备和一个记录设备和CPU之间所有PCIe流量的时间戳的应用程序组成。它们使用设备驱动程序写入MMIO位置，该位置从中断处理程序映射到设备，以创建第二个时间戳。