我正在寻找有助于估算x86 CPU上的中断延迟的信息。非常有用的论文发现于“datasheets.chipdb.org/Intel/x86/386/technote/2153.pdf”。但是本文为我提出了一个非常重要的问题：如何定义等待完成当前指令所提供的延迟？我的意思是识别INTR信号和执行INTR微代码之间的延迟。我记得，英特尔软件开发人员手册还讲述了等待完成当前正在执行的指令的事情。但它也说明了一些指令可能正在中断。主要问题是：如何为特定处理器定义最大完成指令等待长度。需要估算核心节拍和内存访问操作，而不是秒或微秒。应考虑缓存和TLD未命中以及其他可能影响等待的内容。
需要进行此估算以研究实施不会影响中断延迟的小关键部分的可能性。要实现这一点，关键部分的长度必须低于或等于CPU最长的不间断指令的长度。
非常欢迎任何形式的帮助。如果你知道一些可能有用的论文，请分享它的链接。
答案 0 :(得分：3)
如果agner雾优化手册（补充了intel开发人员手册）没有任何内容，那么其他人/其他任何东西都不太可能（除了一些内部的intel / amd数据）：http://www.agner.org/optimize/
答案 1 :(得分：2)
通常，没有保证中断延迟的上限。考虑以下示例：
sti指令（设置IF标志）来禁用可屏蔽中断。hlt指令，处理器将转换为C1睡眠状态。在这种情况下，处理器将不会处理该中断，除非发生不可屏蔽的中断以唤醒处理器，并且将IF标志清零以启用处理可屏蔽的中断。
如果所有应该处理该中断的处理器都处于非常深的睡眠状态，则任何中断（包括不可屏蔽的中断）的中断等待时间都可以达到数百微秒。在我的Haswell处理器上，C7状态的唤醒延迟为133微秒。如果您遇到问题，则可以使用Linux内核参数intel_idle.max_cstate（如果使用了intel_idle驱动程序，这是Intel处理器的默认设置）或processor.max_cstate（对于acpi_idle驱动程序）限制最深的C状态。您可以使用idle=poll告诉内核不要让任何内核进入睡眠状态，这可以最大程度地减少空闲内核的中断等待时间，当然还可以假设由于热调节而不会降低频率。使用轮询环路还会降低所有内核的最大Turbo频率，这可能会降低系统的整体性能。
在活动内核上（状态C0），仅当内核处于可中断状态时才接受硬件中断。此状态发生在指令边界处，但可中断的字符串指令除外。在接受待处理的中断之前，英特尔不对已退休的指令数量提供上限。合理的实现可能会停止在指令边界处向ROB发送微指令，并等到ROB中的所有微指令都退出后，才开始执行用于调用中断处理程序的微代码例程。在这样的实现中，中断等待时间取决于退休所有待处理的微指令所花费的时间。高延迟指令（例如负载，复杂的浮点算术和锁定指令）可以轻松使中断延迟达到数百纳秒的数量级。但是，如果挂起的微指令之一出于某种原因（或某些特定原因）需要微码辅助，则处理器可以选择刷新指令和所有后续指令，而不是调用辅助。此实现以增加的中断等待时间为代价提高了性能和功耗。
在为最小化中断延迟而优化的另一种实现中，所有运行中的指令都将立即刷新而不会退出任何内容。但是所有这些经过流水线的冲洗指令，其中一些可能已经完成，需要获取并在中断处理程序返回时再次通过流水线。这会导致性能降低和功耗增加。
大多数中断不需要在处理中断之前就从存储缓冲区中提交已退休的存储（请参阅：Interrupting an assembly instruction while it is operating）。我知道的唯一例外是SMI中断。根据V3的34.3.1：
当处理器收到SMI时，它将等待所有指令 退休并完成所有商店。
因此，特别是处理SMI中断可能比其他中断花费更多时间。
Intel的标题为Reducing Interrupt Latency Through the Use of Message Signaled Interrupts的论文讨论了一种测量PCIe设备中断延迟的方法。本文使用术语“中断等待时间”来表示您提到的论文中的“中断响应时间”。您需要以某种方式在中断到达处理器时加上一个时间戳，然后在中断处理程序的最开始处加上另一个时间戳。可以通过将两者相减得出中断等待时间的近似值。问题当然是获得第一个时间戳（也可以与第二个时间戳相比）。英特尔论文建议使用PCIe分析器，该分析器由一个PCIe设备和一个应用程序组成，该应用程序记录所有PCIe流量以及设备和CPU之间的时间戳。他们使用设备驱动程序从中断处理程序写入映射到设备的MMIO位置，以创建第二个时间戳。