)為提高即時效能,設計和最佳化 Microsoft Windows CE .NET(上)

來源:互聯網
上載者:User
文章目錄
  • Windows CE .NET
  • Windows CE 3.0
  • 更多優先順序層級
  • 更多地控制時間和調度
  • 計時器中斷
  • OEMIdle 函數
  • 線程時間片
  • 更改處理優先順序倒置的方法
  • 中斷處理和嵌套中斷
  • 嵌套中斷
  • 中斷延隔時間
  • ISR 延隔時間
  • IST 延隔時間
(轉)為提高即時效能,設計和最佳化 Microsoft Windows CE .NET(上)

摘要:本文從技術角度詳細描述了為了增強即時效能特徵而設計的對 Microsoft Windows CE 作業系統 (OS) 作出的更改。它還討論了可用於測試即時效能的工具,並提供了特定硬體設定的有代表性的即時效能測試結果。


本頁內容

簡介
對核心的更改
即時測量工具
效能測量
小結

簡介

對於高效能的嵌入式應用程式所需要的對時間要求嚴格的響應來說,即時效能是不可缺少的,例如,電信交換裝置、工業自動化與控制系統、醫學監視裝置和空間導航和制導系統。這樣的應用程式必須在指定的時間參數以內即時地傳遞它們的響應。

即時效能是什嗎?對於 Microsoft Windows CE .NET OS,以下列表定義了即時效能:

有關高優先順序線程調度的擔保的上限 — 只針對所有已調度線程中的最高優先順序線程。

調度高優先順序插斷服務常式 (ISR) 過程中有關延遲的擔保上限。搶佔機制在一個短暫、有限的時間內關閉後核心有很少的空間。

對排程器和它如何調度線程進行細緻的控制。

重要的是應當區分即時系統和即時 OS (RTOS)。即時系統由滿足系統要求所需的所有元素(硬體、OS 和應用程式)組成。RTOS 只是完整的即時系統的一個元素,它必須提供足夠的功能,才能使全部即時系統能夠滿足它的要求。

儘管以前的 Windows CE 版本提供了某些 RTOS 功能,但自從 Windows CE 3.0 以後很多重要的核心更改極大地增強了即時效能。Windows CE .NET 核心包含了與 Windows CE 3.0 相同的即時增強功能,除此之外還有某些額外的功能。本文描述了作為 Windows CE .NET 及其以前版本的組成部分的以下更改:

Windows CE .NET

對 x86 平台添加了通過 OEM 定義的變數指定頁面池大小的功能。

Windows CE 3.0

增加了線程優先順序層級的數目(從 8 到 256)。

更多地控制時間和調度。應用程式可以控制提供給每個線程的時間,並操縱對它們有好處的排程器。現在,對於與休眠和等待相關的API (API),計時器精確到一毫秒。

處理優先順序倒置的方法得到改進。

全面支援嵌套中斷。

ISR 和中斷服務線程 (IST) 延隔時間得到減少。

更細粒度的記憶體管理控制。

此外,本文描述了用來測試核心即時效能的工具,並提供了在三種不同 CPU 上的即時效能測試結果。

返回頁首

對核心的更改

核心是 Windows CE OS 的內部核心,它負責調度和同步線程、處理異常和中斷、載入應用程式和管理虛擬記憶體。在 Windows CE 3.0 中,為了提高效能和減少延隔時間,核心經曆了以下幾個更改:

將所有核心資料結構移動到實體記憶體,從而當在核心中執行非搶佔代碼時極大地避免了轉換後備緩衝區 (TLB) 損失。

所有非搶佔、但可中斷的核心部分(稱為 KCALL)被分割成更小的非搶佔節。由於增加了節數,這就引入了某些複雜性,但現在搶佔機制能夠在更短的時間內關閉。

這一節描述為了增強 Windows CE 3.0 的即時效能對核心的進一步更改。

更多優先順序層級

核心的排程器首先使用較高的優先順序層級運行某個線程,然後使用相同的優先順序以迴圈方式運行多個線程。為線程指派優先順序層級是管理執行速度的一種方式。

Windows CE 3.0 將可用於線程的優先順序層級數從 8 增加到 256,0 是最高的優先順序,255 是最低的優先順序。Windows CE 的前一版本的優先順序層級 0 到 7 對應於 Windows CE 3.0 中層級 248 到 255。更多的優先順序層級允許開發人員更靈活地控制嵌入式系統的調度,並防止由於限制優先順序層級數使隨機應用程式降低系統效能。

要指派這些新的優先順序,Windows CE 3.0 引入了兩個新函數:CeSetThreadPriorityCeGetThreadPriority。新函數與 Windows CE 2.12 中的 SetThreadPriorityGetThreadPriority 函數看起來完全相同,不過新函數接受的數字範圍是 0 到 255。

更多地控制時間和調度

Windows CE 3.0 已經改進了計時器效能,計時器和休眠函數調用的精度達到了一毫秒,並且應用程式可以為每個線程設定時間片。

計時器(或系統時鐘)是一種速率,由 OS 以此速率產生計時器中斷並對其提供服務。以前,計時器也是線程時間片,是線程沒有被搶佔的情況下可以在系統中啟動並執行最長時間。在 Windows CE 3.0 中,計時器不再直接與線程時間片相關。

以前,OEM 將計時器和時間片作為 OEM 適配層 (OAL) 中的常量設定為大約 25 毫秒。計時器觸發時,如果一個線程已做好準備,核心會調度此新的線程。在 Windows CE 3.0 中,計時器總是設定為一毫秒,並且可以對每個線程設定時間片。

通過將計時器從 OEM 定義的數字更改為一毫秒,可以讓應用程式執行 Sleep(1) 函數,並預計得到大約一毫秒的精度。當然,這取決於線程的優先順序、其他線程的優先順序以及是否正在運行 ISR。以前,Sleep(1) 經過一個系統周期後返回,這意味著如果計時器被設定為 25 毫秒,則 Sleep(1) 實際上是 Sleep(25)

計時器中斷

現在,核心有幾個新的變數,開發人員可以使用它們確定系統時鐘是否需要重新調度。通過在適當的時候返回 SYSINTR_NOP 標誌而不是 SYSINTR_RESCHED 標誌,完整實現的系統時鐘 ISR 可以防止核心被重新調度。Nk.lib 匯出在 Timer ISR 中使用的以下變數:

dwPreempt 是線程被搶佔之前的毫秒數。

dwSleepMin 是第一次逾時(如果有)到期之前的毫秒數,需要重新調度。

ticksleft 是已經過去、但尚未被排程器的休眠隊列處理的系統時鐘數;因而,非零值將導致重新調度。

在 Timer ISR 中,其他邏輯將最佳化排程器,並防止核心執行不必要的工作,如以下程式碼範例所示。

if (ticksleft || (dwSleepMin && (DiffMSec >= dwSleepMin)) || (dwPreempt &&       (DiffMSec >= dwPreempt))) return SYSINTR_RESCHED; return SYSINTR_NOP;
OEMIdle 函數

OEM 實現 OEMIdle 函數,在沒有要調度的線程時核心將調用該函數。在以前的版本中,計時器時鐘會強制 OS 脫離空閑狀態,並返回到核心以確定是否線程已做好調度準備。如果沒有線程做好準備,核心再次調用 OEMIdle。該操作將導致核心每隔 25 毫秒(或 OEM 指定的其他時間片長度)被啟用一次,以確定是否仍然沒有要調度的線程。在電池供電的裝置上,這樣的操作會耗盡寶貴的電池電量。

在 Windows CE 3.0 中,為了在時鐘頻率較高的情況下減少耗電量,OEMIdle 函數可以讓 CPU 進入待機模式一毫秒以上。OEM 通過使用 dwSleepMinDiffMSec 變數來編程設定系統時鐘計時器,以便在第一個可用的逾時後喚醒。DiffMSec 是自從通過 TimerCallBack 函數檢索到最後一次間隔時間以來的當前毫秒值。

硬體計時器的最大逾時值可能小於 MAX_DWORD 毫秒值,所以可以編程設定計時器的最大等待時間。在所有情況下,系統從空閑狀態返回時,OEMIdle 函數必須使用已經過去的實際毫秒數更新 CurMSecDiffMSecCurMSec 是間隔時間的當前值 £ 即自從啟動以來的毫秒數。

線程時間片

在 Windows CE 3.0 中,線程時間片很靈活,足以使應用程式能夠逐個線程地設定時間片。這就讓開發人員可以改編排程器,以滿足應用程式的當前需要。為了調整時間片,已經添加了兩個新函數:CeGetThreadQuantumCeSetThreadQuantum。這項更改使應用程式能夠基於線程完成任務所需要的時間量來設定線程的時間片。通過將任何線程的線程時間片設定為零,迴圈調度演算法可以變為“運行到完成”演算法。只有較高優先順序的線程或硬體中斷才能先於設定為運行到完成的線程執行。

預設時間片是 100 毫秒,但在 OEM 初始化階段,OEM 可以通過將核心變數 dwDefaultThreadQuantum 設定為大於零的任何值,從而重寫系統的預設值。

更改處理優先順序倒置的方法

為了有助於縮短回應時間,Windows CE 3.0 更改了它的優先順序倒置方法,當低優先順序線程擁有一個較高優先順序線程所需要的核心對象時,就會發生優先順序倒置。Windows CE 使用優先順序繼承來處理優先順序倒置,這時,被阻塞的、擁有較高優先順序線程所需要的核心對象的線程將繼承更高的優先順序。優先順序倒置使較低優先順序線程能夠運行,並釋放資源供較高優先順序的線程使用。以前,核心處理整個倒置鏈。從 Windows CE 3.0 開始,核心保證只處理優先順序倒置到一個層級的深度。

優先順序倒置有兩個基本樣本。第一個是簡單的情況,這種情況下,對優先順序倒置的處理從 Windows CE 2.12 到 Windows CE 3.0 沒有變化。例如,在有三個處於運行狀態的線程時,可以看見這種情況。線程 A 的優先順序是 1,線程 B 和 C 優先順序較低。如果線程 A 正在運行,並且因為線程 B 擁有線程 A 需要的核心對象而使 A 被阻塞,那麼線程 B 的優先順序會提高到 A 的優先順序層級,以便允許線程 B 運行。然後,如果因為線程 C 擁有線程 B 需要的核心對象而使線程 B 被阻塞,則線程 C 的優先順序會提高到 A 的優先順序層級,以便允許線程 C 也能運行。

第二個並且是更有趣的情況是,線程 A 可以以比 B 和 C 更高的優先順序運行,線程 B 擁有 A 需要的核心對象,線程 B 被阻塞,等待 C 釋放它需要的核心對象,而 C 正在運行。在 Windows CE 2.12 中,當 A 運行然後因為 B 而被阻塞時,B 和 C 的優先順序都會提高到 A 的優先順序,以便使它們能夠運行。在 Windows CE 3.0 中,當 A 因為 B 而被阻塞時,只有線程 B 的優先順序被提高。通過減少複雜性和更改演算法,極大地減少和限制了 Windows CE 中最大的 KCALL。

中斷處理和嵌套中斷

即時應用程式使用中斷作為確保 OS 快速地注意外來事件的方式。在 Windows CE 內,核心和 OAL 經過調整,以便最佳化對系統的其餘部分的中斷傳遞和事件調度。Windows CE 通過將中斷處理拆分為下面兩個步驟,對效能與實現的容易性進行平衡:插斷服務常式 (ISR) 和中斷服務線程 (IST)。

每個硬體插斷要求線 (IRQ) 都與一個 ISR 相關。允許中斷並出現中斷時,核心會調用該中斷的註冊 ISR。ISR 作為中斷處理的核心模式部分,將儘可能保持簡短。它的責任主要是指引核心啟動適當的 IST。

ISR 執行最低程度的處理,並向核心返回中斷標識符。核心檢查返回的中斷標識符,並設定將 ISR 連結到 IST 的相關事件。IST 等待該事件。核心設定事件時,如果 IST 是準備啟動並執行最高優先順序線程,IST 將停止等待,並開始執行它的其他中斷處理。大多數中斷處理實際上發生在 IST 以內。

嵌套中斷

在 Windows CE 3.0 以前的版本中,ISR 正在運行時,所有其他中斷都會關閉。這將使核心無法處理任何其他中斷,直到一個 ISR 已經完成為止。所以如果高優先順序中斷已做好準備,核心不會處理新的中斷,直到當前的 ISR 已經完成操作並返回到核心為止。

為了防止高優先順序中斷丟失和延遲,Windows CE 3.0 基於優先順序添加了對嵌套中斷的支援(如果 CPU 或其他相關硬體支援它)。ISR 在 Windows CE 3.0 中運行時,核心將像以前一樣運行指定的 ISR,只是禁用了相同和較低優先順序的 ISR。如果較高優先順序的 ISR 做好運行準備,核心將儲存正在啟動並執行 ISR 的狀態,並讓較高優先順序的 ISR 運行。核心可以嵌套 CPU 可支援的最大數量的 ISR。ISR 按硬體優先順序的順序進行嵌套。

大多數情況下,OEM 的當前 ISR 代碼不會更改,因為由核心處理詳細資料。如果 OEM 在 ISR 之間共用全域變數,則可能需要變更,但通常,ISR 不知道它們已經被較高優先順序的 ISR 所中斷。如果 ISR 定期地執行操作,則可能會發生顯而易見的延遲,但延遲只有當較高優先順序的 IRQ 被觸發時才會發生。

最高優先順序的 ISR 結束之後,將執行任何掛起的較低優先順序的 ISR。然後,核心繼續處理任何被中斷的 KCALL。如果線程正在被調度並在 KCALL 中間被中斷,則排程器會繼續處理線程。這將使核心能夠從它停止的地方繼續執行,而不用完全重新啟動對線程的調度,從而節約了寶貴的時間。一旦掛起的 KCALL 完成操作,核心將重新調度線程的執行,並開始執行做好運行準備的最高優先順序的線程。

中斷延隔時間

核心即時效能的一個最重要的特性是能夠在指定的時間內服務 IRQ。中斷延隔時間主要是指軟體中斷處理延隔時間 £ 即從外部中斷到達處理器的時間直到中斷處理開始的時間所經過的時間。

如果不發生分頁操作,Windows CE 3.0 中斷延隔時間被限制於記憶體中鎖定的線程。這樣就可以計算最糟糕情況下的延隔時間 £ 到 ISR 的啟動和到 IST 的啟動的總計時間。然後,在中斷被處理以前的時間總量可以通過計算在 ISR 和 IST 中所需要的時間來確定。

ISR 延隔時間

ISR 延隔時間是從 IRQ 在 CPU 中被設定時到 ISR 開始運行時的時間。以下三個與時間相關的變數會影響 ISR 的啟動:

A 中斷在核心中關閉的最長時間。核心很少關閉中斷,但如果將它們關閉,則關閉的時間長度會受到限制。

B 在核心調度中斷和 ISR 被實際調用之間的時間。核心使用該時間確定要運行什麼 ISR,並儲存在繼續之前必須儲存的任何寄存器。

C 在 ISR 返回到核心和核心實際停止處理中斷之間的時間。這是核心通過還原在 ISR 被調用之前被儲存的任何狀態(例如寄存器)來完成 ISR 操作的時間。

正在測量的 ISR 的啟動時間可以基於系統中其他中斷的目前狀態進行計算。如果中斷進行中,則計算要測量的新 ISR 的啟動時間必須考慮到兩個因素:所關注的中斷已經發生之後將發生的較高優先順序中斷的數量,以及執行 ISR 所佔用的時間。以下樣本說明了所得到的啟動時間。

Start of ISR =

 

這裡,NISR 是將在已發生所關注的中斷之後發生的較高優先順序中斷的數量;TISR(N) 是執行 ISR 所需要的時間。下面的圖 1 說明了該公式。

1. ISR 啟動時間公式的圖形表示

如果沒有發生較高優先順序中斷 (NISR=0),則前面的公式將簡化為以下的程式碼範例。

Start of ISR = A + B

Windows CE 和 OEM 都會影響執行 ISR 的時間。Windows CE 控制變數 A、B 和 C,它們都會受到限制。OEM 控制 NISR 和 TISR(N),它們都可以極大地影響 ISR 延隔時間。

IST 延隔時間

IST 延隔時間是從 ISR 完成執行(即通知線程)到 IST 開始執行的時間。以下四個與時間相關的變數會影響 IST 的啟動時間:

B 核心調度中斷和 ISR 被實際調用之間的時間。核心使用該時間確定要運行什麼 ISR,並儲存在繼續之前必須儲存的任何寄存器。

C 在 ISR 返回到核心和核心實際停止處理中斷之間的時間。這是核心通過還原在 ISR 被調用之前儲存的任何狀態(例如寄存器)來完成 ISR 操作的時間。

L KCALL 中的最長時間。

M 調度線程的時間。

在 ISR 返回到核心並且核心執行某些工作來開始執行 IST 之後最高優先順序 IST 開始的啟動時間。在 ISR 返回並通知 IST 開始運行之後,IST 啟動時間受所有 ISR 的總計時間的影響。下面的樣本說明了所得到的啟動時間。

Start of highest priority IST =

 

說明了該公式。

2. 最高優先順序 IST 啟動時間公式的圖形表示

Windows CE 和 OEM 都會影響執行 IST 所需的時間。Windows CE 控制變數 B、C、L 和 M,它們都是受限制的。OEM 控制 NISR 和 TISR(N),它們可以極大影響 IST 延隔時間。

Windows CE 3.0 還對 IST 添加了以下限制:連結 ISR 和 IST 的事件處理只能用在 WaitForSingleObject 函數中。Windows CE 3.0 防止 ISR-IST 事件處理被用在 WaitForMultipleObjects 函數中,這意味著核心可以擔保觸發事件的時間和釋放 IST 的時間有一個上限。

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.