這篇文章中提出了兩種支援 ARM 新雙核架構 Coretex-A15 &
Cortex-A7 的可能實作方式。原本 ARM big.LITTLE 期望達
到可以使用 Coretex-A15 的高效能與 Coretex-A7 的低功耗
，達到兩種市場通吃的多核 cpu cluster 系統。
Linux scheduler 原本預期的多核系統，都是假設每顆核心
Linux scheduler 原本預期的多核系統，都是假設每顆核心
的工作效能相等，因此要在 Linux 支援 ARM big.LITTLE 的
異質多核，勢必需要改變原有的 Linux kernel，才可能決定
何時將哪一個 kernel task 交由 Coretex-A15 或 Coretex-A7
執行？以享受到 ARM big.LITTLE 的高效能與省電的雙效果。
針對 Linux 整合 ARM big.LITTLE 架構的可能性，文中提出
針對 Linux 整合 ARM big.LITTLE 架構的可能性，文中提出
兩種可實作方式。
第一種是 ARM 的參考實作使用了 Coretex-A15 與 Coretex-A7
第一種是 ARM 的參考實作使用了 Coretex-A15 與 Coretex-A7
的虛擬化功能，讓作業系統 ARM big.LITTLE 的多核心硬體
只有一組 Coretex-A15 cluster (4 核)的虛擬核心。
對於 Linux scheduler 來說因為仍可以安全的套用多核心的
對於 Linux scheduler 來說因為仍可以安全的套用多核心的
硬體都是同等效能與耗電量，如此 hypervisor 可以在作業
系統不知情的狀態下，將整個執行狀態從某一個 cluster
suspend，再搬移到另一個 cluster resume 繼續執行。對
作業系統來說差異是會發現速度的改變(看是在 big
Coretex-A15 或是 LITTLE Coretex-A7 執行)。
優點是對已經支援 Coretex-A15 多核的作業系統可無痛轉換
優點是對已經支援 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 工作頻率的操作介面
不用改變。
