估計 x86 CPU 上的中斷延遲

Question

我正在尋找有助於估計 x86 CPU 上的中斷延遲的信息。 這篇非常有用的論文位於“datasheets.chipdb.org/Intel/x86/386/technote/2153.pdf”。 但是這篇論文為我打開了一個非常重要的問題：如何定義等待當前指令完成提供的延遲？ 我的意思是識別 INTR 信號和執行 INTR 微代碼之間的延遲。 我記得，英特爾軟件開發人員手冊還介紹了有關等待當前執行指令完成的內容。 但它也說明了一些指令可以在進行中被中斷。 主要問題是：如何為特定處理器定義最大完成指令等待長度。 需要對核心滴答和內存訪問操作進行估計，而不是以秒或微秒為單位。 應該考慮緩存和 TLD 未命中以及其他可能影響等待的類似因素。

需要這種估計來研究實現不會影響中斷延遲的小關鍵部分的可能性。 為此，臨界區的長度必須小於或等於 CPU 最長的不可中斷指令的長度。

任何形式的幫助都非常受歡迎。 如果你知道一些有用的論文，請分享它的鏈接。

Answer 1

如果 agner 霧的優化手冊（與英特爾開發人員手冊一起補充）沒有任何內容，那么任何人/其他任何東西都不太可能（除了一些內部英特爾/amd 數據）： http : //www.agner.org/optimize/

Answer 2

通常，中斷延遲沒有保證的上限。 考慮以下示例：

• 通過執行設置 IF 標志的sti指令禁用可屏蔽中斷。
• 處理器通過執行hlt指令轉換到 C1 睡眠狀態。
• 發生可屏蔽中斷，其關聯指定它只能在該處理器上處理。

在這種情況下，處理器將不會處理中斷，直到發生不可屏蔽中斷以喚醒處理器並且清除 IF 標志以啟用處理可屏蔽中斷。

如果所有應該處理中斷的處理器都處於非常深度的睡眠狀態，則任何中斷（包括不可屏蔽中斷）的中斷延遲都可能在數百微秒的數量級。 在我的 Haswell 處理器上，C7 狀態的喚醒延遲為 133 微秒。 如果這對您來說是個問題，您可以使用 Linux 內核參數intel_idle.max_cstate （如果使用 intel_idle 驅動程序，這是 Intel 處理器的默認值）或processor.max_cstate （對於 acpi_idle 驅動程序）來限制最深的 C -狀態。 您可以使用idle=poll告訴內核永遠不要讓任何內核進入睡眠idle=poll ，這可以最大限度地減少空閑內核上的中斷延遲，當然前提是頻率不會因熱節流而降低。 使用輪詢循環還會降低所有內核的最大 Turbo 頻率，這可能會降低系統的整體性能。

在活動內核（處於狀態 C0）上，僅當內核處於可中斷狀態時才接受硬件中斷。 該狀態發生在指令邊界處，但可中斷的字符串指令除外。 英特爾不提供在接受掛起中斷之前退出的指令數量的上限。 一個合理的實現可以停止向 ROB 發出 uops（在指令邊界處）並等到 ROB 中的所有 uops 在開始執行微代碼例程以調用中斷處理程序之前退休。 在這樣的實現中，中斷延遲取決於退出所有未決微指令所需的時間。 加載、復雜的浮點運算和鎖定指令等高延遲指令很容易使中斷延遲達到數百納秒的數量級。 然而，如果未決微指令之一出於任何原因（或某些特定原因）需要微碼輔助，則處理器可以選擇刷新指令和所有后續指令，而不是調用輔助。 這種實現以增加中斷延遲為代價提高了性能和功耗。

在另一個為最小化中斷延遲而調整的實現中，所有進行中的指令都會被立即刷新，而不會退出任何內容。 但是，當中斷處理程序返回時，所有這些通過管道的刷新指令以及其中一些可能已經完成的指令需要被提取並再次通過管道。 這會導致性能降低和功耗增加。

硬件中斷會耗盡 Intel 和 AMD x86 處理器上的存儲緩沖區和寫入組合緩沖區。 請參閱：在運行時中斷匯編指令。

Intel 的一篇題為Reducing Interrupt Latency Through the Use of Message Signaled Interrupts 的論文討論了一種測量 PCIe 設備中斷延遲的方法。 本文使用術語“中斷延遲”來表示與您提到的論文中的“中斷響應時間”相同的含義。 您需要在中斷到達處理器時以某種方式獲取時間戳，然后在中斷處理程序的最開始處獲取另一個時間戳。 可以通過將兩者相減來計算中斷延遲的近似值。 問題當然是獲取第一個時間戳（也是以與第二個時間戳相當的方式）。 Intel 的論文建議使用 PCIe 分析器，它由一個 PCIe 設備和一個應用程序組成，該應用程序記錄設備和 CPU 之間所有帶有時間戳的 PCIe 流量。 他們使用設備驅動程序寫入從中斷處理程序映射到設備的 MMIO 位置，以創建第二個時間戳。