後藤弘茂のWeekly海外ニュース
海外のオクタコア版GALAXY S4の「big.LITTLE」ソフトウェアアーキテクチャ
（2013/5/21 14:09）
GALAXY S4のExynos 5 Octaが初のbig.LITTLE製品
Samsungがワールドワイドで発売した新スマートフォン「GALAXY S4」のチップアーキテクチャ面での目玉は「big.LITTLE」アーキテクチャ(日本のNTTドコモ版は異なる)。big.LITTLEは、ARMがアーキテクチャ面で省電力化を実現するために導入した新アイデアで、高パフォーマンスのbig CPUと、低消費電力のLITTLE CPUの両方を搭載することで、平均消費電力を抑える。
GALAXY S4の半数の機種が搭載する自社製モバイルSoC(System on a Chip)「Exynos 5 Octa」の場合は、高負荷時には1.6GHzのCortex-A15(半導体のスペック上は最高1.8GHz以上)、低負荷時には1.2GHzのCortex-A7と、負荷に応じてCPUコアを切り替える。Cortex-A15とCortex-A7はそれぞれクアッドコア(4コア)構成で、合計でオクタコア(8コア)となる。といっても、現状ではCortex-A15とCortex-A7は切り替えて使うため、同時に動作しているコア数は4コアとなる。ピークパフォーマンスは、原理的にはCortex-A15クアッドコアと同等だが、平均消費電力は単なるCortex-A15クアッドよりぐっと低くなる。
big.LITTLEは、2011年秋にARMが発表して以来、注目を集めて来たが、今回のSamsung製SoCでついに現実の製品として登場した。Samsungが一番乗りを果たすことができた背景にはソフトウェア開発がある。また、その背後には、Intelに対して圧倒的に弱いARM陣営のシステムソフトウェア開発&最適化の態勢という事情がある。
ARMは、2011年にbig.LITTLEを発表した当時は、仮想化を使ってCPUコアを切り替えると説明していた。しかし、SamsungのGALAXY S4でのbig.LITTLEの、ソフトウェア層の実装は仮想化を使っていない。その代わりに、AndroidのLinuxカーネルの中で、CPUコアをスイッチする「In-Kernel Switcher(IKS)」を使う。
このIn-Kernel SwitcherはARM自身が提供したものでも、Samsungが独自で開発したソフトウェアでもない。ARMベースのLinuxコアテクノロジの共同開発のための非営利エンジニアリング組織Linaroが開発したものだ。Linaroの狙いは、自社ハードウェアのためのソフトウェア層の開発を膨大なリソースで行なうIntelに、ARM陣営が対抗できるようにすることにある。ますます複雑化するハードウェアのために、ソフトウェア開発量は膨れ上がっており、ソフトウェアの共同開発が必要となっている。
2種類のCPUコアで低消費電力を実現するbig.LITTLE
ARMのbig.LITTLEプロセッシングは、ヘテロジニアス(Heterogeneous:異種混合)マルチコアを省電力化のために利用するアイデアだ。命令セットレベルでは完全互換だが、パフォーマンスと消費電力の異なる2種類のCPUコアを実装し、タスクの負荷に応じてCPUコアを切り替える。高負荷のタスクはハイパフォーマンスCPUコアで短時間に実行し、低負荷のタスクは省電力コアで走らせることで、高パフォーマンスと低電力を両立させる。大半のタスクは低消費電力コアで走るため、平均消費電力は抑えられる。
ARMはそのために、ハイパフォーマンスコアのCortex-A15と互換の低消費電力コアCortex-A7、それに両コアの間でキャッシュコヒーレンシを取る仕組みを用意した。より複雑になり、電力消費が増えたCortex-A15を搭載したシステムの、低負荷時の電力消費をCortex-A7で減らす。それによって、モバイルSoCのパフォーマンスと電力の“レンジ”を拡張する。
その背景には、モバイルデバイスに要求されるパフォーマンスレンジの拡張がある。より高いパフォーマンスが必要なアプリが登場する一方、パフォーマンスをあまり必要としないタスクも多数残されている。しかし、バッテリ容量はほとんど伸びないため、ARM CPUはパフォーマンスと電力という相反する要求に、パフォーマンス&電力のレンジを広げることで応えなければならなくなっている。
問題は、単一のCPUアーキテクチャでは、この2つの要求に同時に答えることができない点にある。big.LITTLEでは、2種類の異なるCPUコアを組み合わせることで、この問題を解決する。2種類の異なるパフォーマンスレンジのCPUで、連続的にパフォーマンス曲線をカバーする。
3モデルのbig.LITTLEのソフトウェアモデル
big.LITTLEのチャレンジは、ハードウェアよりソフトウェアの方がはるかに難しいこと。どうやって2種類のコアが混在するマルチコアを効率的に働かせるのか。理想的なのは、OSが負荷の高いタスクをbigコア、負荷の低いタスクをLITTLEコアと、リアルタイムに割り振ることだが、それには幾多のチャレンジがある。そして、OSに特殊な対応が必要になることを、システムベンダーは嫌う。
そのため、2011年にARMは、当初はCPUコアを仮想化して、HypervisorがOSごとCPUコア間を移行させてしまうソフトウェア実装で立ち上げると説明した。ただし、将来的にはOSをbig.LITTLEに最適化して、コアをフルに使うマルチプロセッシングモデルも可能になると示した。この時点では、前者を「big.LITTLEタスクマイグレーションモデル(Task Migration Use Model)」、後者を「big.LITTLE MP(Multiprocessing)モデル(MP Use Model)」と呼んでいた。
タスクマイグレーションモデルでは、Cortex-A15のクラスタと、Cortex-A7のクラスタのどちらか一方が動作する。OS側もアプリは一切コードを変更する必要がなく、HypervisorがCPUコアのスイッチをハンドルする。実際に、この実装でプロトタイプソフトウェアは作られた。
しかし、その後、ARMは路線を変更した。2012年秋の同社のカンファレンス「ARM Techcon」では、タスクマイグレーションと呼んでいたモデルを「クラスタマイグレーションモデル(Cluster Migration Model)」に名称変更。その上で、クラスタマイグレーションはプロトタイプのみで終わり、実際の製品向けには提供されないことになった。
現在、ARMはbig.LITTLEに関して3つのユースモデルを示している。プロトタイプのみのbig.LITTLEクラスタマイグレーションと、OSにスイッチャソフトを加えて実現する「big.LITTLE CPUマイグレーションモデル(CPU Migration Use Model)」、big.LITTLE MPモデルの3ユースモデルだ。新たにCPUマイグレーションモデルが加わり、これがbig.LITTLE立ち上げ時のモデルとして推奨された。また、CPUマイグレーションモデルとMPモデルのどちらについてもソフトウェアの開発をLinaroが行なっていることも明らかにされた。
CPUマイグレーションモデルと、最初のクラスタマイグレーションモデルの大きな違いは、CPUクラスタ単位ではなく、CPUコア単位でスイッチする。bigコアとLITTLEコアを1対1でペアリングして、それぞれのペアの中で片方のコアだけがオンになる。LITTLEコアで走らせていたタスクの負荷が高い場合に、ペアになったbigコアに移行させる仕組みだ。ARMはCPUマイグレーションモデルが、今年(2013年)前半に利用可能なソフトウェアソリューションだと説明していた。
big.LITTLEを立ち上げるCPUマイグレーションモデル
big.LITTLEのCPUマイグレーションモデルで最も重要なポイントは、CPUコアのスイッチにHypervisorを使わないが、OSのスケジューラにも変更を加えない点にある。ちょうど、クラスタマイグレーションと、MPモデルの中間のようなソリューションだ。
CPUマイグレーションモデルが産まれたのは、そもそも、ARMが当初提唱したクラスタマイグレーションモデルが実用的ではなかったためだという。その一方で、MPモデルはOSのスケジューラを変更しなければならないため、実装に時間がかかり、big.LITTLEの立ち上げに間に合わなかった。そこで、CPUマイグレーションのアイデアが浮上したとLinaroの塚本明氏(メンバーサービス、FAE&サポートエンジニア)氏は説明する。
「クラスタマイグレーションは、クラスタ単位なので同時にはCortex-A15とA7のどちらかしか動作しない。しかし、それよりも問題だったのは、スイッチングをHypervisor経由で行なっていることだった。Hypervisorに入ってスイッチしてHypervisorから出るため、2回タスクスイッチが発生する。そのため、CPUのサイクルだけで300サイクルを消費し、さらにL2フラッシュなどで合計3,000サイクル程度を消費して、かなり遅かった。
クラスタマイグレーションは、迅速にスイッチできないため、実際の製品レベルでは問題があるという結論になった。そこで、ARM側からは、次にbig.LITTLE MPができるかと言う話が出てきた。しかし、今年(2013年)の前半の製品では、MPのソフトウェア開発に無理がある。そこで、Linaroのコアメンバーとクラブメンバーだけで、CPUコアマイグレーションを作って実装しようという話になった。昨年(2012年)の12月までに完成させて、Samsungの発売に間に合わせた」(塚本明氏)。
ARMは当初はクラスタマイグレーションでも、スイッチングのブランクは問題にならないと説明していたが、現実はそう行かなかったようだ。現実解が、CPUマイグレーションモデルだったというわけだ。
こうした事情から、現在、Linaroで開発したCPUマイグレーションモデルのソフトウェアは、Linaroのメンバーにしか提供されていない。そして、Linaroに注力するSamsungが、それによってbig.LITTLEの製品化を果たすことができた。
Linuxのスケジューラには変更を加えずbig.LITTLEをサポート
CPUマイグレーションモデルの利点は、OS側からはCPUコアは対称型のSMP(Symmetric Multi-Processor)構成に見えているのに、ハードウェア的には非対称なAMP(Asymmetric Multiple Processor)構成である点。Samsungの例で言えば、AndroidのLinuxカーネルからは、ハードウェアはクアッドコアのSMP構成に見えている。ところが、実際にはCortex-A15のクアッドとCortex-A7のクアッドの、2種類8コアが混在するAMP構成だ。
そして、CPUマイグレーションモデルでは、Linuxカーネルのスケジューラ自体には手を加えない。これは重要なポイントで、開発期間を短くできた理由でもある。
「Linuxカーネルのスケジューラのソースコードは1万行程あるが、それには一切タッチしない。その下にアドオンで単純な2,000行くらいのコードを足して、CPUコアのスイッチを行なわせている。OSのスケジューラからは仮想的にCPUコアは4つにしか見えない。しかし、その下でCortex-A7とA15を勝手に切り替えている。切り替えるスイッチャがカーネルの中に入っているのでインカーネルスイッチャ(In-Kernel Switcher：IKS)と呼んでいる」(塚本氏)。
In-Kernel Switcher(IKS)がOSのスケジューラをだますことで、SMPと見せかけながら、AMP構成を有効に使う仕組みとなっている。アドオンのIKSを使うことでOSの根本機能であるスケジューラのコードには変更を加えずに済ませている。Linuxの歴史でも、スケジューラの変更は2回程度しか行なわれておらず、それを改変しようとすると大変な作業になってしまうため、IKSという抜け道を使った。
LinaroのIKSは、CPU負荷に応じて2つのコアを切り替える。切り替えの遷移ポイントの決定には、負荷に応じてCPUコアの電圧と動作周波数を切り替える「DVFS(Dynamic Voltage and Frequency Scaling)」の仕組みを使ってる。Linuxの場合は、CPUFreq Governorと呼ばれるサブシステムがあり、CPU使用率をモニタしてCPUの動作周波数を遷移させる。IKSは、Governorからの情報で、DVFSが一定のポイントに達した時にCPUコアをスイッチさせる。
そのため、OS側はDVFSでCPUの周波数を遷移させているつもりでいるが、実際にはその下で、IKSが一定のDVFSポイントから下はCortex-A7、上はCortex-A15という具合に振り分ける。もっとも、実際にはCortex-A7とCortex-A15では周波数レンジが異なり、Cortex-A7の最高周波数から、Cortex-A15の最低周波数へと遷移する。そのため、IKSでは、バーチャルOPP(Operating Performance Point)を設定して、Cortex-A7とCortex-A15それぞれの実際のDVFSポイントにマップしている。OSから見えるのは、バーチャルOPPとなる。
LinaroのIKSで立ち上がった非対称型のAMP構成のbig.LITTLEアーキテクチャ。次のステップは、big.LITTLE MPモデルの実現となる。MPモデルでは、タスクのCPU負荷に応じて、混在する全てのコアに適切にタスクが割り当てられるようにするとARMは説明していた。しかし、これにはさまざまなチャレンジがある。それは、OS側がタスクのCPU負荷を知る術が極めて限られているからだ。
