Linux 支援 ARM big.LITTLE 架構的方式

摘譯 http://lwn.net/Articles/481055/

這篇文章中提出了兩種支援 ARM 新雙核架構 Coretex-A15 & Cortex-A7 的可能實作方式。原本 ARM big.LITTLE 期望達到可以使用 Coretex-A15 的高效能與 Coretex-A7 的低功耗，達到兩種市場通吃的多核 cpu cluster 系統。

Linux scheduler 原本預期的多核系統，都是假設每顆核心的工作效能相等，因此要在 Linux 支援 ARM big.LITTLE 的異質多核，勢必需要改變原有的 Linux kernel，才可能決定何時將哪一個 kernel task 交由 Coretex-A15 或 Coretex-A7 執行？以享受到 ARM big.LITTLE 的高效能與省電的雙效果。

針對 Linux 整合 ARM big.LITTLE 架構的可能性，文中提出兩種可實作方式。

第一種是 ARM 的參考實作使用了 Coretex-A15 與 Coretex-A7 的虛擬化功能，讓作業系統 ARM big.LITTLE 的多核心硬體只有一組 Coretex-A15 cluster (4 核)的虛擬核心。

對於 Linux scheduler 來說因為仍可以安全的套用多核心的硬體都是同等效能與耗電量，如此 hypervisor 可以在作業系統不知情的狀態下，將整個執行狀態從某一個 cluster suspend，再搬移到另一個 cluster resume 繼續執行。對作業系統來說差異是會發現速度的改變(看是在 big Coretex-A15 或是 LITTLE Coretex-A7 執行)。

優點是對已經支援 Coretex-A15 多核的作業系統可無痛轉換，但缺點是 hypervisor 需要多考慮 Coretex-A15 與 Coretex-A7 的 cache 等系統實作細節的差異。另一個衍生問題是每次 hypervisor 轉換 cluster 的 performance penalty 是否造成另一種資源浪費？

第二種是利用 Linux Kernel 原有的 cpu driver cpufreq 的架構，將不同的 Coretex-A15 與Coretex-A7 工作頻率排列組合後，當作一個虛擬的 cpu freq 設定。這方法的好處是上層 user space 控制 kernel cpu 工作頻率的操作介面不用改變。