翻譯：Windows and Real-Time——Daniel Terhell

標籤：dispatch   操作模式   機制   檢索   添加   virtual   count   綁定   事件   

“ Windows不是即時作業系統”，這句話反覆在NTDEV論壇中被提到。當某個人嘗試為非Windows相容的裝置（比如一個期望軟體在很短的時間片之內響應的裝置）寫一個外掛程式的時候，通常會遇到這個問題。 即時作業系統的定義是，在滿足最低要求的情況下，以可預計的方式執行。它必須嚴格確保在很短的時間片之內響應請求。通常可以分為軟即時和硬即時環境。對於軟即時，最重要的是快速響應，一次請求丟失不會造成整體失敗。在硬即時環境中，作為對比，不允許任何意料之外的延時，任何請求丟失意味著整體失敗。通常這樣的環境都支援即時任務。 在Windows裡，所有對作業系統的請求都基於最佳效果來處理，不保證回應時間。因此，Windwos能夠在1秒鐘時間內處理成千上萬的請求，簡單來說，它不能確保每個請求會在指定的時間片中被處理。 在大多數使用中，Windows是基於效能和輸送量來設計和最佳化的，不是為了即時任務和低延遲，這通常是有衝突的。針對大多數使用所關注的平均吞吐效能的最佳化方案，和針對即時請求關注的最大回應時間的解決方案相比，最糟糕的結果是請求丟失。這意味著每一個獨立的請求或操作都很重要。 有很多即時請求相關的解決方案，範圍從工業、醫學、軍工、航空、科研到高精度多媒體應用。舉個簡單的要求即時性的應用，“即時音頻”，比如軟體合成器，需要發聲以響應MIDI鍵盤的按鍵，延時不能超過幾毫秒。音頻流必須是連續的，任何單擊、彈出和釋放都可能中斷音頻流，影響音頻結果。這意味著所有的請求都符合截止時間。 事實上，即時應用中的延時問題，比如“在發聲之前按鍵”延時問題，原來就有，而不是電腦時代的產物。比如說，風琴手，必須預讀並在好幾秒鐘後才能聽到他們演奏的聲音，空氣必須經過複雜的機制在管道中流動，聲音必須從教堂的角落回傳到耳朵。 在使用聲音合成器和音頻外掛程式時，即時音頻應用中的延時問題，通常有他們使用者模式下的實現邏輯。就是說相較於運行在IRQL（Interrupt ReQuest Level插斷要求）的裝置驅動，他們更加有機會被中斷（比如翻頁、計劃）。 最後，注意本文的目的，我們忽略特定的Windows特性，如基於某些特定用途的IRQL PASSIVE_LEVEL中斷處理和UMDF，通常不是為即時處理而設計的。  低延時的敵人 為了便於理解，為什麼Windows不是合適的即時處理作業系統，我們仔細看一個中斷驅動裝置的實現，它要在截止時間內在使用者模式下處理請求。然後我們一邊解釋哪些問題會造成不受歡迎的延時。 對於一個中斷驅動的即時性敏感的裝置，Windows能夠及時響應請求是很重要的。對於接下來將要討論的即時處理的敵人，延時可能在即時處理中被引入。邏輯上，在一次中斷的處理期間，IRQL降的越低，從ISR到DPC再回到使用者處理，越有可能引起長時間和頻繁的延時。  中斷/ISR 裝置指示需要引起軟體注意的方法，是產生一個中斷。CPU收到裝置發出中斷訊號後，將該中斷註冊為一個ISR（Interrput Service Routine）來處理。 ISR的執行可能被種因素延遲。CPU可能臨時延遲中斷，作業系統正在為一個進階的中斷服務，臨時停用一些可屏蔽的中斷，造成整個系統的鎖定狀態或者其他。同樣的，中斷可能被硬體因素延遲。遺憾的是，這類中斷延遲不能單獨通過軟體來測量。需要硬體的支援，或者使用匯流排分析【在現代Intel架構系統中，我們知道硬體延時是非常小的，通常小於1毫秒】。本文中，我們僅討論中斷處理中的軟體延時，就是從ISR開始處理到中斷被軟體處理的期間。 因為Windows不允許控制裝置中斷的優先順序，任何ISR執行的時候可以被更進階的中斷搶佔，除非通過提升IRQL來阻止此類搶佔。ISR處理過程中的延時，也可能由其他因素引入，比如處理系統時鐘、IPI（Inter Processor Interrupt）常式引起的作業系統中斷，或者不受作業系統控制的因素，比如SMI（System Management Interrupt）常式，以及稍後會討論的其他各種硬體因素。  DPC 如果該中斷的服務需要長時間運行，ISR通常規劃一個DPC（Deferred Procedure Call）。DPC在一個較低的IRQL上處理I/O操作，裝置和系統中斷可以搶佔他的執行。如果中斷的服務需要以使用者模式進行，也需要一個DPC，受IRQL的強加在ISR的限制不允許恢複等待的對象或喚醒使用者模式的線程。 一般，DPC在請求以後馬上在同一個處理器上執行。作業系統為每個邏輯處理器維護一個DPC隊列，很有可能其他DPC常式在你的之前運行，當你的處理器上的DPC隊列很繁忙的時候，因此增加了延時。 因為DPC常式在IRQL的DISPATCH_LEVEL（線程DPC是一個例外，它執行在PASSIVE_LEVEL）執行，處理DPC的過程中任何裝置或硬體中斷都可能引起延時。 CPU收到一個中斷開始到DPC常式開始執行的時間間隔，通常表述為“ISR到DPC延時”。如果驅動要求有截止時間，它需要最小化ISR到DPC最大延時。這是個重點，不要錯過它：對於即時處理，我們關注的是最大延時，而不是平均延時。ISR到DPC平均延時通常都很好。換句話說，ISR到DPC的最大延時有時候會帶來令人吃驚的壞處。這也是經常引入人工產品的地方（如下）。按規則執行另一方面，作為一個核心開發人員，儘管你的驅動沒有任何即時性需求，你也需要關注平穩的執行，避免花太多時間關注IRQL，這樣你不會損害你的驅動所在作業系統的即時性。包括花在ISR、DPC以及代碼執行中的自迴圈鎖或者通過其他途徑提升的IRQL的時間。或者你是一個BIOS/韌體開發人員，需要更加關注這些。MSDN對此的建議是，任何DPC或ISR常式都不能執行超過100微秒。實踐中，許多驅動違反了此規則，至少在特定的硬體上。如果一個驅動引起了高延時，這並不總意味這是軟體的錯，許多情形中此類問題可以完全歸因於硬體。網路驅動（特別是WIFI），儲存連接埠驅動以及ACPR電池驅動，都是臭名昭著的在中斷執行期間引起高延時的驅動。通常在執行即時性任務時，這些驅動要在系統中禁用。  使用者模式 在即時性請求處理模式下，要避免執行使用者模式代碼。然而有些情況和解決方案依賴於此。當使用者模式代碼在重要的方式中執行時，顯然代碼必須執行的越快越好。使用者模式代碼不應該掛起、等待或者調用任何Windows API庫函數。它應該只是用常駐記憶體，因為硬體分頁錯誤會引髮長時間掛起執行線程，等待分頁錯誤處理器通過從地盤讀取同步資料來解決它，這通常要消耗數秒鐘時間。 注意Windows API函數，如VirtualLock只允許向處理器的工作集合執行一個分配，並不為應用程式提供常駐RAM的記憶體。一個確保應用程式取得常駐記憶體的做法是，讓驅動將使用者提供的緩衝鎖定到記憶體中。有很多方法可實現它，一些方法比另一些更加複雜。一個簡單的方法是，在IOCTL中通過使用METHOD_OUT_DIRECT，由使用者應用程式分配緩衝，然後提供給驅動作為輸出緩衝（OutBuffer）。驅動就可以在執行過程中保持這個緩衝，及其鎖定的記憶體，直到應用程式退出為止。也有其他更加複雜的方法，在使用者模式和核心模式之間鎖定共用記憶體。這些方法的優缺點不在本文的討論範圍內。 作為中斷執行的一部分的使用者模式線程，通常在一個即時性優先順序線程池中管理，處於空閑狀態被掛起，被從DPC常式中設定的一個調度對象訊號喚醒，比如事件或者I/O結束。 從處理器收到一個中斷到使用者模式線程被喚醒後開始執行的時間周期，通常稱為“ISR到處理器延時”。包括為該處理器規劃一個DPC並執行的時間。在作業系統課程中，這通常被稱為“處理器分配延時”。一個部分工作在使用者模式的有時間要求的解決方案，必須最小化ISR到處理器延時。 當一個即時關鍵的使用者模式的線程要長時間執行的時候，作業系統的規劃器通過給使用者模式線程一個“超級”即時優先順序，來允許它不被搶佔，這樣它的時間不會到期。包括給處理器分配一個特定調度類設定的任務對象。  更多殭屍 除了硬體中斷、ISR常式、DPC常式、使用者模式執行和硬體頁面損壞（hard page faults）之外，底層還有其他低延時的敵人不能被忽略，因為他們能引起顯著的延時。現在我們來討論其中一些問題。 Inter Processor Interrupts是作業系統啟動中斷，當一個特定常式在所有邏輯處理器上執行時，會掛起所有裝置中斷。他們可以由硬體和軟體觸發。驅動，如ndis.sys利用這種技術，伴隨著大量DPC處理，就是啟用網路設定的作業系統通常不適合即時處理的原因。 SMM（System Management Mode）是處理器的一種專用操作模式，用來處理全系統層級的函數，如電源管理、系統硬體管理或專有的OEM代碼。只應該被BIOS或韌體介面使用，不能被應用程式或其他動作系統使用。系統管理中斷（System Management Interrupt）是在SMM中執行的CPU中斷常式，在作業系統之外。SMI的優先順序在任何可屏蔽或非遮罩式插斷之上。因為SMI可以在任何時候中斷任何處理，它需要被儘可能快的執行，否則在執行即時性任務時將造成全系統不可用。 一個啟用變速設定的CPU核心，在臨時設定為“stop clock mode”若干毫秒之後可以達到很高的溫度，需要降溫。這個處理器上的中斷將被掛起，直到CPU可以再次運行為止。 CPU的設計缺陷也會導致不可解釋的CPU宕機。現代CPU中的一些CPU缺陷，和處理器的C-states（實現CPU空閑）以及P-state（實現CPU變速）相關，可以無限期凍結一個處理器，直到滿足某些條件為止。CPU製造商發布包含這些資訊的勘誤表（規格更新）。 上面提到的許多引起延時的因素，不是可以由開發人員在軟體層面控制的，除非修改系統配置。然而通過軟體衡量作業系統的即時效能力是可行的，這樣終端使用者可以檢查他的系統是否適用。  測量延時 我們列出了許多潛在的危險，對於一個有即時性要求的驅動。如果一個驅動要支援一個現成的有即時性需求的硬體在任意系統上運行，基本不會成功。所以在安裝或購置之前測試一個系統的能力，以免失敗和引起客戶不滿，或者通過協助終端使用者配置系統以克服運行你的解決方案的障礙，是很有協助的。 有一些工具讓你可以測量ISR和DPC時間。其中一個是XPERF，是可選安裝的Windows效能工具包的一部分。Windows效能工具包，包含在Windows WDK和SDK中。關於如何使用XPERF，點擊（Get Low - Collecting Detailed Performance Data With Xperf） 另一個工具是LatencyMon，除了ISR和DPC時間之外，還提供硬體分頁錯誤（hard page faults）。此外還提供不同的延時測量工具，包括ISR to DPC以及ISR to user process延時。LatencyMon是本文作者寫的。 作為驅動代碼的作者，通過使用KeQueryPerformanceCounter函數自己添加測量點是微不足道的。要測量你DPC常式的執行時間，你可以簡單的在常式的開始和結束查詢效能計數，比較之間的差異即可。改方法同樣也可以測量ISR to DPC和ISR to user的執行延時。 以前使用的一種測量DPC延時的技術是，安裝一個核心周期計時器，來測量精確中斷的間隔。Windows的計時器是基於軟體的，依賴於時鐘中斷的精度。作業系統的時鐘是全域資源，一些軟體組件和應用程式會競爭它，只有低刻度的請求會勝出（有最低要求的應用程式勝出）。因為Windows的計時器沒有直接硬體支援，就是說它們不是非常精確。在Window8更加如此，因為引入了新特性“動態時鐘節拍”，系統時鐘不再在確定的間隔後中斷，而是在作業系統認為必要的時候，基於節省電量的原因。這使得任何依賴核心計時器的測量方法都不可靠。如果一個裝置需要在軟體中以精確的時鐘訪問，硬體需要內建能觸發中斷的計時器，使得軟體可以及時的提供服務。這就是事實，儘管Windows8.1有一個新特性叫做高精度計時器。 從WIndows Vista開始，Windows提供一系列函數和類，來檢索作業系統核心收集的事件跟蹤資訊。其中，這讓你可以獲得系統中執行的ISR和DPC的資訊，以及硬體分頁錯誤。遺憾的是，這些類不支援你收集進階IRQL的時間消耗，基於ISR和DPC之外的原因，比如運行在自旋鎖和IPI的代碼。 一個測量SMI最大執行時間和無法解釋的處理器停頓的方法，是測量在ISRQL的HIGH_LEVEL輪詢的緊密迴圈的最進階中斷。這個投機方法然而，不會測量軟體發起的SMI常式的執行。 同樣的，你可以測量IPI的執行時間，通過在低於IPI_LEVEL的較低的IRQL執行迴圈。需要考慮的一件事是，有些版本的作業系統可以使用一種叫做“lazy IRQL”的IRQL管理技術。在這種技術下，作業系統儲存的IRQL值，不總是和處理器的任務優先順序狀態對應。 中斷綁定在處理器上。Windows允許完整配置使用你系統中的哪個處理器來執行線程，通過設定偏好，而幾乎沒有哪個處理器處理裝置中斷的控制。執行關聯特定裝置的ISR的處理器，和硬體最為相關，因此Windows將BIOS設定用於中斷偏好。有的晶片集讓中斷在所有的處理器上傳播，另一些僅僅讓中斷在CPU 0上執行。這使得運行在特定硬體上的軟體通過偏好選擇哪個處理器來運行，是沒用的。這種情況不同於你可以提供你自己的作業系統的情況，我們稍後將討論。GetProcessorSystemCycleTime API函數是一種簡單快速的方法，找出系統的哪個處理器在處理中斷和DPC。  硬體控制 前面提到的，如果你在為一個裝置或解決方案開發即時性驅動，可能部署在某些系統上不能滿足要求，因為特定的系統配置。 如果你有幸在你的解決方案啟動並執行系統上有豐富的控制選項，那你有可能擁有由你支配的選項來避免失敗。對於哪些使用現成產品的開發人員，這些選項是不開放的。依賴於你的解決方案的截止時間和市場需求，選擇一個特定的作業系統配置能讓你提交一個能確保工作的解決方案。 一旦作業系統的配置完全在你的掌控之下，你就有了添加額外的硬體來支援你處理延時敏感任務的機會。一個選項在硬體層面實現即時邏輯，比如使用FPGA或者DSP開發板。也有WIndowns的即時（軟體）擴充，允許你獲得即時性而不需要額外的硬體，比如IntervalZero RTX和Tenasys Intime。這些解決方案通過伴隨Windows運行一個獨立的作業系統，負責即時邏輯的處理。 但是儘管沒有外來硬體或者即時性擴充，仍然有很多可以做，在你控制整個作業系統的情況下。如果你的解決方案要求的回應時間（或精確性）不是非常高，比如超過10毫秒，那你通過配置已知的硬體和驅動不會帶來高延時的Windows作業系統，可以提交一個Windows上啟動並執行解決方案，也可以滿足截止時間的要求。 通過仔細的選擇配置中的母片晶片組和驅動，可以控制哪個處理器串連到中斷，允許你通過偏好為即時性關鍵任務預留一個或多個處理器，可有效避免ISR和DPC帶來的延時。配置哪個CPU處理ISR、DPC和線程，可以更進一步通過特定的處理器組參數來啟動作業系統，經過測試以後。 自訂配置的一個重要部分是電源管理。就像前面討論的，一些CPU和BIOS的電源管理特性可造成即時性處理的延時。若可能，禁用這些特性，可避免即時處理中的不當延時。 音頻行業的使用者做了很多研究，在如何配置他們的Windows工作站上，以獲得低延時，所以網上有很多資訊。推薦使用DAW（Digital Audio Workstation）關鍵詞。當然也有電腦架構師，定製裁剪和提供案頭電腦和筆記本，以在Windows上處理低延時任務。  總結 你可以看到，使得Windows系統能夠處理即時任務，需要一些測量、解惑，甚至考慮一些不特定的因素。在為你的解決方案配置和測試一個系統之後，你可能仍然覺得不舒服，在給你的客戶提供保證方案經得起測試和分析的時候。 記住：Windows不是RTOS。如果你的解決方案需要Windows確保的回應時間，你可能大部分時候，需要你的解決方案依賴終端使用者的配置。問題就轉變為，多少情況下你的即時性需求不能被滿足，不滿足這些需求的結果是什麼，是否有任何裁剪或者系統配置需要執行來提高結果。希望這篇文章解釋了問題，如何客服一些問題，以及有哪些資源可用，對於需要在Miscosoft Windows下交付一個即時性敏感的解決方案的核心開發人員。 原文串連：https://www.osr.com/nt-insider/2014-issue3/windows-real-time/http://thehub.musiciansfriend.com/tech-tips/tech-tip-optimizing-windows-for-daws

翻譯：Windows and Real-Time——Daniel Terhell