x86 CPU上中断延迟的估计

我正在寻找有助于估计x86 CPU中断延迟的信息。这篇非常有用的论文可以在“datasheets.chipdb.org/Intel/x86/386/technote/2153.pdf”上找到。但这篇论文向我提出了一个非常重要的问题：如何定义等待完成当前指令所带来的延迟？我指的是识别INTR信号和执行INTR微代码之间的延迟。我记得，《英特尔软件开发人员手册》还讲述了等待当前正在执行的指令完成的情况。但它也说明了某些指令在执行过程中可能会被中断。主要问题是：如何为特定处理器定义最大完成指令等待长度。需要估计内核时钟和内存访问操作，而不是以秒或微秒为单位。应该考虑缓存和TLD未命中，以及其他可能影响等待的因素

需要进行此评估，以调查实施不会影响中断延迟的小型关键部分的可能性。要实现这一点，关键部分的长度必须小于或等于CPU最长不间断指令的长度

---

欢迎任何形式的帮助。如果你知道一些有用的文章，请分享这些文章的链接。

如果agner fog的优化手册（由英特尔开发人员手册提供）没有任何内容，那么其他人/任何东西都不可能有（除了一些英特尔/amd内部数据）：

一般来说，中断延迟没有保证上限。考虑下面的例子：

• 通过执行设置IF标志的

  sti

  指令来禁用可屏蔽中断
• 处理器通过执行

  hlt

  指令转换为C1睡眠状态
• 发生可屏蔽中断，其关联性指定只能在该处理器上处理该中断

在这种情况下，处理器将不处理中断，直到发生不可屏蔽中断以唤醒处理器，并且清除IF标志以允许处理可屏蔽中断

如果所有处理中断的处理器都处于深度睡眠状态，则任何中断（包括不可屏蔽的中断）的中断延迟可以达到数百微秒。在我的Haswell处理器上，C7状态的唤醒延迟为133秒。如果这是您的问题，您可以使用Linux内核参数

intel\u idle.max\u cstate

（如果使用intel\u idle驱动程序，这是英特尔处理器上的默认值）或

processor.max\u cstate

（对于acpi\u idle驱动程序）来限制最深的C状态。您可以使用

idle=poll

告诉内核永远不要将任何内核置于睡眠状态，这可能会最小化空闲内核上的中断延迟，当然，假设频率不会由于热节流而降低。使用轮询环路也会降低所有内核的最大turbo频率，这可能会降低系统的整体性能

在活动内核（状态C0）上，仅当内核处于可中断状态时，才接受硬件中断。此状态发生在指令边界处，但字符串指令除外，它是可中断的。英特尔不提供接受挂起中断前失效指令数的上限。合理的实现可以停止向ROB发出UOP（在指令边界处），并在开始执行微码例程以调用中断处理程序之前，等待ROB中的所有UOP退役。在这种实现中，中断延迟取决于使所有挂起的UOP失效所需的时间。高延迟指令（如加载、复杂浮点运算和锁定指令）很容易使中断延迟达到数百纳秒。但是，如果某个挂起的UOP出于任何原因（或某些特定原因）需要微码辅助，处理器可以选择刷新指令和所有后续指令，而不是调用辅助。这种实现以增加中断延迟为代价，提高了性能和功耗

在另一个优化为最小化中断延迟的实现中，所有正在运行的指令都会立即刷新，而不会使任何指令失效。但是，所有这些经过管道的刷新指令，其中一些可能已经完成，都需要获取，并在中断处理程序返回时再次通过管道。这会导致性能降低和功耗增加

硬件中断会耗尽Intel和AMD x86处理器上的存储缓冲区和写组合缓冲区。请参阅：

---

Intel的一篇题为“讨论一种测量PCIe设备中断延迟的方法”。本文使用术语“中断延迟”来表示与您提到的论文中的“中断响应时间”相同的含义。您需要在中断到达处理器时获取一个时间戳，然后在中断处理程序的最开始处获取另一个时间戳。中断延迟的近似值可以通过减去这两个值来计算。当然，问题是获取第一个时间戳（同样以与第二个时间戳相当的方式）。Intel论文建议使用PCIe分析器，该分析器由PCIe设备和应用程序组成，该应用程序使用设备和CPU之间的时间戳记录所有PCIe通信量。他们使用设备驱动程序写入从中断处理程序映射到设备的MMIO位置，以创建第二个时间戳。

注意，满是缓存未命中存储的存储缓冲区可能会导致相当高的延迟，然后IRQ处理程序中的任何存储才会可见。