鑒于處理器和應用程序的復雜性增加，當前一代操作系統（OS）主要關注軟件完整性，而部分忽略了從現有硬件中提取最大性能的需求。

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

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

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

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

先進的性能管理解決方案

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

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

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

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

擴展到更多維度

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

了解每個任務的時間以及它是正在運行還是等待運行，使軟件能夠自動確定最小時鐘速度和運行時間。因此，在所有負載條件下，一切都按時完成。將時鐘速度與瞬時工作負載相匹配并不意味著時鐘速度始終最小化。低能耗的目標有時需要高速爆發，然后是空閑，就像英特爾的 HUGI 一樣。但即便如此，運行速度超過最佳利用率（每單位時間執行的操作）所指示的速度也沒有好處。在等待內存操作完成時快速計時不會節省能源。

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

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

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

在 VMX Linux 上的實現

PerfMan已實現為獨立于常駐操作系統運行的瘦內核（sdKernel）。它已移植到 Linux 2.6.29 （VMX Linux），如圖 2 所示。安卓端口即將完成。該軟件接管 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% 的平均負載，并及時完成。

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

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