處理器的性能與操作系統允許的一樣好。一個計算平臺，無論是嵌入式的還是其他的，不僅包括物理資源——內存、CPU 內核、外圍設備和總線——通過資源分區（虛擬化）取得了一些成功，還包括性能資源，如 CPU 周期、時鐘速度、內存和I/O 帶寬和主/高速緩存內存空間。這些資源由諸如優先級或時間片之類的古老方法管理，或者根本不管理。結果，處理器未被充分利用并消耗過多能量，從而剝奪了它們真正的性能潛力。

大多數現有的管理方案都是分散的。CPU 周期由優先級和時間隔離管理，這意味著需要在預設時間內完成的應用程序將保留該時間，無論它們是否真的需要它。由于緩存未命中、未命中推測和 I/O 阻塞導致執行時間無法安全預測，因此保留時間通常比需要的時間長。為了確保智能手機中的調制解調器堆棧接收到足夠的 CPU 周期來進行呼叫，可能會限制其他應用程序不能同時運行。這就解釋了為什么一些無名品牌手機的用戶抱怨當電話響起時，GPS 會掉線。

除此之外，電源管理最近引起了極大的興趣。注意“分離”的特征。大多數部署的解決方案擅長檢測空閑時間、使用系統響應緩慢的模式，或 CPU 可以以較低時鐘速度運行從而節省能源的特定應用程序。例如，英特爾提出了 Hurry Up and Get Idle （HUGI）。要理解 HUGI，請考慮這個類比：有人可以使用 Indy 汽車全速到達目的地然后將其停放，但也許使用 Prius 及時到達目的地會更實用。您認為哪個使用較少的氣體？基于使用模式的電源管理粒度太粗，無法始終有效地挖掘所有節能機會。

理想情況下，開發人員希望改變時鐘速度/電壓以匹配瞬時工作負載，但這不能僅通過關注正在運行的應用程序來實現。開發人員可能能夠確定應用程序按時完成的最低時鐘速度，但他們是否可以在不知道其他等待運行的應用程序如果延遲會受到影響的情況下減慢時鐘速度？單獨管理任務和時鐘速度（功率）并不能帶來最佳的能源消耗。獲勝的方法將同時管理/優化所有性能資源，但至少管理時鐘速度和任務調度。想象一下，任務調度器是旅行計劃者，時鐘管理器是汽車司機。如果汽車減速，則必須重新計劃行程。驅動程序可能由于糟糕的路況（緩存未命中）而不得不減速或在鐵路障礙處停下（多線程中的障礙，由于分配的 I/O 帶寬不足而導致緩沖區空時阻塞，等等）。表現出依賴于數據的執行時間的應用程序也存在一個問題，因為它們完成的時間直到它們完成才知道。應該提前為這些應用程序分配什么時鐘速度？

先進的績效管理解決方案

管理性能資源的一個示例是 VirtualMetrix 性能管理 （PerfMan），它通過參數驅動算法控制所有性能資源。該軟件根據帶寬消耗和指令退役等性能數據安排任務、更改時鐘速度、確定空閑期并分配 I/O 帶寬和緩存空間。這種方法（如圖 1 所示）解決了碎片問題，并可以實現最佳資源分配，甚至考慮到現代處理器和數據相關應用程序的執行速度的不可預測性。

圖 1： PerfMan 使用參數驅動算法控制所有性能資源，從而實現最佳資源分配。

正在申請專利的已完成工作分配算法使用閉環方法，通過比較已完成的工作與仍需完成的工作來做出分配決策，以系統提供的任何可測量的性能量表示。例如，如果應用程序是填充緩沖區的視頻播放器或通信協議，PerfMan 可以跟蹤緩沖區填充級別并確定時鐘速度和運行時間，以便及時填充緩沖區。完成的時間不可避免地會有所不同，因此決策會周期性更新。在許多情況下，緩沖區被過度填充以防止緩沖區空時阻塞，這可能導致時序違規。PerfMan 能夠進行精確的性能分配，將緩沖保持在最低限度并減少內存占用。該算法可以處理硬、軟、

如果應用程序執行圖被量化為簡單的性能參數，并且在重要時知道截止日期，那么算法將動態調度以及時滿足截止日期。即使是非實時應用程序也需要一些性能分配以避免無限期延遲。分配應用程序所需的最少處理器資源會提高系統利用率，從而可能產生更高的工作負載。該方法不依賴于嚴格的優先級，盡管可以使用它們。執行的優先級或順序是應用程序在等待輪到運行時表現出的緊迫性的直接結果，這是要執行的基本工作/已完成工作范式的函數。

擴展到更多維度

如果任務已準備好在現有操作系統中運行，它們將運行，但它們需要嗎？如果操作系統知道它不會影響它們的操作，它們可以被延遲（強制空閑）嗎？

了解每個任務的時間以及它是否正在運行或等待運行相對于其完成進度，允許軟件自動確定最小時鐘速度和運行時間。因此，在所有負載條件下，一切都按時完成。將時鐘速度與瞬時工作負載相匹配并不意味著時鐘速度總是最小化。低能耗的目標有時需要在空閑之后出現高速爆發，例如英特爾的 HUGI。但即便如此，運行速度超過最佳利用率（每單位時間執行的操作）所表明的速度并沒有任何好處。等待內存操作完成時的快速時鐘不會節省能源。

該算法“以最低能耗實現最高利用率/工作負載”的口號在很大程度上是通過管理所有性能資源的閉環算法來實現的。

在多核系統中，不能同時實現負載均衡、多線程屏障延遲低和總能耗最低。為了解決這個問題，可以將 PerfMan 配置為優化一個或多個性能屬性。如果以最低能耗為目標，一個不平衡的系統，其中一些內核負載高，而其他內核為空并因此關閉，可能會以更長的執行延遲和整體較低的性能為代價提供最低的能耗。

加速線程以減少屏障延遲也會導致更高的能耗。但是，滿足最后期限（硬的或軟的）優先于所有其他考慮。精確的基于閉環的性能資源分配算法可以安全地保持更高的工作負載水平，這反過來又可以比現有方法更進一步地推動核心整合，從而實現更高的能耗降低。

在 VMX Linux 上實現

PerfMan 已實現為獨立于駐留操作系統運行的瘦內核 （sdKernel）。它已被移植到 Linux 2.6.29 （VMX Linux），如圖 2 所示。Android 移植即將完成。該軟件接管了 Linux 任務調度并與現有的電源管理基礎架構互通。sdKernel 的一個單獨版本提供虛擬化并支持在符合 POSIX 的環境中的硬實時任務。調度/上下文切換在許多平臺上處于亞微秒級，但由于大多數 Linux 系統調用對于硬實時應用程序來說太慢了，因此 sdKernel 為基本外圍設備、定時器和其他資源提供了 API。

圖 2：在 Linux 實施中，PerfMan 接管 Linux 任務調度并與現有的電源管理基礎架構互通。

通過監控性能，該軟件可以檢測異常的執行模式，從而預測即將到來的操作系統恐慌和崩潰。在這種情況下，sdKernel 將通知關鍵任務應用程序停止使用 Linux 系統調用，并在 Linux 重新啟動時臨時切換到 sdKernel API（安全模式）。

VMX Linux 支持實時和非實時應用程序的混合，具有高效的性能隔離，同時將能耗降至最低。它還可以提供硬件隔離/安全和安全迫降。

基準測試顯示結果

使用 VMX 設計的能量計實時測量的能量消耗為系統累積并與各個應用程序相關聯。媒體播放器應用程序（視頻和音頻）首先使用標準 Linux 2.6.29（圖 3 紅色圖表）和 VMX Linux（圖 3 藍色圖表）在 OMAP35xx BeagleBoard 上運行。

圖 3：在 OMAP35xx BeagleBoard 上使用 VMX Linux 可實現 95% 的平均負載并及時完成。

性能合規性（Perf Compl 圖）顯示應用程序任務按時完成的距離（中心線）。線下方表示違反截止日期。請注意，使用 VMX Linux，可以實現 95% 的平均負載，而無需預緩沖，也不會違反最后期限，但它已經接近了。使用 VMX Linux 時，46 秒視頻的總電路板能耗從 68.7 W*sec 下降到 27.6 W*sec。顯示的數據代表預設時間間隔內的平均值。作為額外的獎勵，當 Linux 被故意崩潰時，視頻會消失，但音樂會在安全模式下播放，不會出現任何可聽見的故障。

簡而言之，該實施創造了一種新的績效管理方法，并取得了令人興奮的結果。

審核編輯：郭婷