低延遲中斷處理（預計從內核返回到用戶空間的平均時間是？）

我有一個光纖鏈路，並帶有一個專有的設備驅動程序。
鏈接進入PCIe卡。在RHEL 5.2上運行（2.6.18-128〜）
我有mmap用於設置和FIFO訪問等卡上的接口，這些讀/寫需要幾μs才能完成，所以一切都很好。低延遲中斷處理（預計從內核返回到用戶空間的平均時間是？）

但是當然不能使用這個中斷，所以我必須使用提供的內核模塊，以及它的用戶空間lib接口。

WaitForInterrupt(); // API lib interface to kernel module 
// Interrupt occurs and am returned to my code in user space 
time = CurrentTime() - LatchedTime(); // time to get to here

從WaitForInterrupt（）返回需要大約70μs。（中斷髮生的時間被鎖存在固件中，我讀到這個，正如我上面所說的那樣需要〜2μs，並將其與固件中的當前時間進行比較）

中斷髮生和用戶空間API中斷調用等待方法返回？

網絡/其他高速接口需要嗎？

來源

2010-09-18 Ian Vaughan

Linux不是一個實時操作系統。 – 2010-09-18 19:42:49

我不認爲我需要實時，只是快速！ – 2010-09-19 09:19:56

如果你能夠可靠地超過500us在一個沒有重負載的系統上，我想你正在研究一個糟糕的驅動程序實現（或其用戶空間封裝器/對應）。

根據我的經驗，喚醒中斷用戶線程的延遲應該小於10us，儘管（正如其他人所說的那樣）Linux不提供延遲保證。

來源

2010-09-20 14:49:47

500ms的是幅度比用戶空間/內核之間的一個簡單的開關需要更大的許多訂單，但在評論中提到某人，Linux不是一個實時操作系統，所以不能保證500毫秒「hickups」不會不時出現。

要判斷罪魁禍首是不可能的，設備驅動程序可以簡化嘗試捆綁數據以提高效率。

這就是說，我們有無盡的煩惱與一些定製卡和互動既APIC和ACPI，requireing的BIOS設置一個微妙的平衡，是什麼牌放在哪個PCI插槽，以及是否在特定的視頻卡搞砸了一切 - 可能是一個可疑的驅動程序與更多或更少的錯誤bios /視頻卡進行交互的原因..

來源

2010-09-18 20:08:01 nos

爲了測量從內核到用戶空間的中斷延遲，我們必須模擬中斷嗎？我試圖看看如何衡量這一點。 – ransh 2017-01-01 19:21:23

如果您有最近的內核，您可以使用perf sched工具來衡量延遲，並查看時間使用。（500us聽起來有點偏高，取決於你的處理器，有多少任務正在運行，......）

來源

2010-09-19 10:41:13 caf

低延遲中斷處理（預計從內核返回到用戶空間的平均時間是？）

回答

相關問題