後藤弘茂のWeekly海外ニュース
2014年のARMのSoCの中核技術となる「big.LITTLE MP」
（2013/12/20 06:00）
IKSからGlobal Task Scheduling(GTS)へと動く技術の流れ
ARMベースSoC(System on a Chip)の省電力技術「big.LITTLE」。big.LITTLEでは、現在、2種類のソフトウェアモデルが提供されている。1つは、Linaro(ARMベースのLinuxコアテクノロジの共同開発のための非営利エンジニアリング組織)が開発した「big.LITTLE In-Kernel Switcher(IKS)」。これは「big.LITTLE CPU Migration」とも呼ばれる。
もう1つは、ARMが開発した「big.LITTLE MP」で、「Heterogeneous MP(HMP)」とも呼ばれる。ヘテロジニアスな構成のCPUコアを、拡張したOSスケジューラで使う技術コンセプト「Global Task Scheduling(GTS)」の現在の実装のパッチセットがbig.LITTLE MPだ。前者はLinaro、後者はARMで、しかも両者でそれぞれの呼び方が異なるためやや混乱しがちになっている。
big.LITTLEでは、大型でパフォーマンスの高いCPUコア(big)と、小型で低消費電力のCPUコア(LITTLE)を組み合わせる。CPUの性能を必要とするタスクはbigコアで走らせ、CPU性能が必要ないアプリはLITTLEコアで走らせる。負荷が小さい時の消費電力を最低限に抑えながら、負荷が高い時にも十分なパフォーマンスを提供する。現在はbigコアが「Cortex-A15」、LITTLEコアが「Cortex-A7」だ。来年(2014年)には64-bitのbigコア「Cortex-A57」とLITTLEコア「Cortex-A53」の組み合わせも登場する。また、「Cortex-A12」もbig.LITTLEで使うことができる。
big.LITTLEはハードウェアとソフトウェアの両方が揃って初めて意図通りに使うことができるようになる。big.LITTLEのソフトウェアソリューションでは、In-Kernel Switcher(IKS)はbigコアとLITTLEコアをペアにして切り替える。そのため、IKSでは、CPUコアは半分の数しか動作しない。bigコアとLITTLEコアがそれぞれ4コアなら、合計8コアのうち4コアしか同時には動作できない。また、bigコアとLITTLEコアを同じ数に揃える必要がある。
それに対して、Global Task Scheduling(GTS)のbig.LITTLE MPでは、bigコアとLITTLEコアの両方に、OSのスケジューラが負荷に応じてタスクを振り分ける。bigコアとLITTLEコアがそれぞれ4コアずつの構成なら、最大で合計の8コア全てを使うことができる。また、bigコアとLITTLEコアが非対称(例えばbigが2コアでLITTLEが3コアなど)な構成でも構わない。また、タスクのアロケーション自体の粒度も小さくなるとARMは説明している。
こうした利点があるため、SoCベンダは、後者のbig.LITTLE MPをメインのターゲットにしてbig.LITTLE対応チップの開発を進めてきた。big.LITTLE対応は最初はSamsungだけだったが、ルネサスや富士通といった日本勢やMediatek、Allwinnerなど海外でバリュー市場に強いベンダなど、対応メーカーが急に増えている。
big.LITTLE MPもアップストリームを目指したが
IKSはLinaroが開発したため、当初はLinaroのメンバー企業だけに公開されていた。Linaroの提供するパッチセットという位置付けだった。しかし、現在はIKSはLinuxのアップストリーム(Linuxのオープンソースコミュニティのコードと、そのコードに還流させること)に統合(v3.13rc1)されている。Linuxの本流に取り込まれ、オープンなソリューションになっている。
それに対して、ARMが開発したbig.LITTLE MPは、アップストリームにはマージしない。ARM側から提供する独自のカーネルパッチセットという位置付けだ。しかし、big.LITTLE MPを開発したARMは、自社の顧客に対してはオープンにしている。ちなみに、パッチ自体はLinaroが提供するカーネル「Linaro Stable Kernel (LSK)」の現在のバージョンに、LinaroのIKSとともにbig.LITTLE MP、ARMv8 Arch64(64-bit命令セット)が含まれている。
もともとの計画では、ARMはbig.LITTLE MPもアップストリームすると説明していた。実際に、ARMはbig.LITTLE MPを主力ラインのLinuxカーネルに推した。Linuxカーネルコミュニティに対してARM側で正面に出ているのはMorten Rasmussen氏だ。しかし、Linuxのアップストリームを管理するメンテナーには容認されなかったという。big.LITTLE MPの実装をアップストリームに取り込むより、もっと本質的にパワーアウエアなタスクスケジューラを開発しようという議論に発展したからだと言う。その背景には、他社からも、省電力を考慮したスケジューラの提案があったこともあるようだ。
big.LITTLE MPは、メインストリームに含まないとはいえ、実装に問題があるということではない。big.LITTLE MPがbig.LITTLEハードウェアできちんと動作することはすでに確認されている。big.LITTLE MPは、カーネルのスケジューラの拡張を最小限に留めて、早い時期に使えるようにすることを念頭に開発されたという。
OSカーネルのスケジューラに手を入れるのはリスキーで時間がかかるが、ハードウェアメーカー側のbig.LITTLEの製品計画はどんどん進んでいる。そのため、製品に間に合わせる形で開発されたのがbig.LITTLE MPだ。それに対してLinuxカーネルコミュニティでは、もっと時間をかけてきちんと省電力に最適化したパワーアウエアスケジューリング(Power-Aware Scheduling)の開発を行ないたいと考えていると言われる。そうした路線の違いのため、big.LITTLE MPはカーネルパッチの形で提供されることになったと見られる。
「run queue」を利用するbig.LITTLE MPのマイグレーションメソッド
では、現在のbig.LITTLE MPはどのように動作しているのか。IKSではOSのスケジューラ自体は手を加えず、その下の周波数ドライバなどの層にIKSを組み込んで対応した。そのため、OSのスケジューラ自体は、big.LITTLEのハードウェアを認識せず、その下のスイッチャソフトウェアがCPUコアを切り替える。それに対して、big.LITTLE MPは、OSのカーネルスケジューラのロードバランサに変更を加えている。スケジューラ自体がbig.LITTLEのハードウェアの違いにアウエアしている。
big.LITTLE MPでは、ロードバランシングの仕組みの中でbig.LITTLEをbigクラスタとLITTLEクラスタの2つのドメインとして区別する。そして、CPUコアへのタスクのロードの比率に応じて、bigとLITTLEの2クラスタ間でタスクを移動させる。LITTLEクラスタのCPUコアで走っている特定のタスクの平均負荷が、あらかじめ決められていたしきい値を超えると、bigクラスタのCPUコアに移動させられるといった仕組みだ。
現在のソフトウェアアーキテクチャでは、OS側にはそのタスクの中身に対する情報を得る手段がほとんどない。一方、タスク側には、OSの下のハードウェアはほぼ隠蔽されている。その制約の中で、big.LITTLEのような新しいアプローチを有効にしようと、ソフトウェア開発者がもがいているのが現在の状況だ。big.LITTLEでは、CPUコアを切り替えるトリガーをどう実装するかは大きな問題となっている。
前回の記事でbig.LITTLE MPもIKSと同じCPUのオペレーティングポイントを使っていると書いたが、これは古い仕様で、現在は異なるという。ARMによると、big.LITTLE MPでは、Linux/Unixでのスケジューラへのキューである「run queue」から得られる「load average」によるCPU負荷の値を使っているという。原則的にはrun queueでの占有率が高くなり、load averageの比率が一定を越えると、そのCPUコアをLITTLEコアからbigコアへと切り替える仕組みだ。
ロードアベレージとロードヒストリを使ってコアをマイグレート
下の例は、LITTLEのCortex-A7が3コア、bigのCortex-A15が2コアの構成の例だ。これは、ARMが試作したテストチップと同じ構成だ。
図の初期状態は、LITTLEコアにスレッドを割り当て、LITTLEコアが3個稼働している状態となっている。3個のLITTLEコアに、それぞれ複数のスレッドが割り当てられており、1個のスレッドがアクティブになっている。この状態で、デマンドの多い(ロード要求の多い)スレッドが検知される。デマンドは、そのスレッドがrun queueに入っている時間で測る。
そして、1つのスレッドのload averageが一定のしきい値を越えると、そのスレッドはbig.LITTLE対応ロードバランス機構によってbigコアへとマイグレートされる。その逆に、load averageが下がると、タスクはLITTLEコアへとマイグレートされる。マイグレートに必要な時間は、現在は最大で32ms。また、マイグレートの決定にかかる時間は1～30msだという。
この方法の場合、スレッドの実行が必ずLITTLEコアから始められると、負荷の高いタスクではbigコアに切り替えるまで遅延が生じてしまう。レスポンスが重要なタスクでは、これは問題となる。そのため、現在のbig.LITTLE MPの場合は、これまでロードしたことがない新しいスレッドをローンチする場合には、まずbigコアに割り当てる仕様となっているという。
ただし、この場合、全てのスレッドが必ずLITTLEコアに割り当てられて立ち上がると、ムダな電力消費が生じてしまう。そこで、big.LITTLE MPではヒストリテーブルをスレッド毎に参照することで、負荷が小さいスレッドはLITTLEコアに割り当てる操作を行なっているという。big.LITTLE MPではOSが、走らせた全スレッドのロードヒストリをトラックして保存する。そのロードヒストリを元に、前回のロードで負荷が高かったスレッドはbigコアへ、負荷が低くすぐに完了してしまったスレッドはLITTLEコアへと、次回のロードから割り振るという。これは、従来のIKSでは行なっていない。
一定水準以上の負荷ならbigコアに留まり続ける
big.LITTLE MPではrunqueueから得られるload averageによってCPU負荷の情報を得ている。big.LITTLE MP側には負荷に対するマイグレーションしきい値(migration threshold)が設定されており、それを越えるとコアを切り替える。ただし、LITTLEからbigへとアップする時のしきい値と、bigからLITTLEへとダウンする時のしきい値は異なる設定がされている。
そのため、しきい値を超えてbigコアに移行したタスクは、その後ある程度負荷が下がってもbigコアに留まり続ける。アップよりも低く設定された、ダウンのしきい値を超えた場合にLITTLEコアに移行する。この仕組みによって、負荷にある程度の波があるタスクも、頻繁にbigとLITTLEの両コアを移行することなく、一定のコアで実行され続ける。
このように、もともとタスクの移動を司っているロードバランサの部分に、CPU負荷に応じてドメインを移行させる機能を加えることで実現するのがbig.LITTLE MPだ。そのため、big.LITTLE MPパッチセットが、タスクの移動を行なうのはbigとLITTLEのクラスタ間に厳密に制限されている。具体的には、SoCの内部のbig.LITTLE構成のコア群に対するタスクの移行だけに対応し、チップ間のロードバランスなどにはアプライされない。ロードバランサの処理の中で、bigとLITTLEのクラスタドメインに関する部分にだけ干渉するように制限することで、本来のロードバランシングの機能に影響が出ないようにしている。
ワークロードによって異なるbig.LITTLE MPの効用
では、big.LITTLE MPはどれだけ効果があるのか。これについては、ARMがARM Techconで説明を行なっている。ARMは、タスクを大きく3種類に分けてbig.LITTLEの効用の説明を行なった。(1)散発的に高いパフォーマンスが要求されるワークロード、(2)持続的に一定以上のパフォーマンスが必要とされるワークロード、(3)低いパフォーマンスしか要求されないワークロードだ。
まず、ピーク時のパフォーマンス要求は高いが長続きせず、低パフォーマンスの時期もあるなど波があるバースト型のワークロードの場合。これは、Webブラウジングなどが典型的なワークロードで、多くのケースでレスポンスが重要となる。こうしたワークロードでは8コア全てを使うことはほとんどないが、bigコアの高い性能がレスポンスのために必要となり、LITTLEコアの省電力性がバックグラウンドタスクで必要となる。また、ゲームの中にもこうしたタイプのワークロードのアプリがあり、ここでもbig.LITTLEが効力を発揮するという。
一方、多くのゲームに見られる、継続してパフォーマンスが必要なワークロードの場合。こうしたゲームは増える一方で、より多くのCPUコアを使い、bigコアの比率も高くなる。ARMによると、こうしたワークロードではbig.LITTLEの効果は歴然としており、bigコアだけの構成に対して電力消費は明確に減るという。また、CPUコアの電力をbig.LITTLEで減らすことで、GPUコアにより電力枠を渡して、GPUコアを高速に駆動できるようにもなるという。
低いパフォーマンスのワークロードの場合は、bigコアは当然使われない。LITTLEコアだけの処理となり、結果としてbigコアだけの構成に対して消費電力は大幅に低減される。
リスクが大きく慎重にならざるを得ないタスクスケジューラの変更
仕組みを見る限り、big.LITTLE MPもタスクの負荷をベースにタスクの移行を行なう機構となっている。big.LITTLE MPのアプローチは現実解で、実装しやすいように見える。実際、来年(2014年)のbig.LITTLE対応製品の多くは、この仕様のbig.LITTLE MPを搭載して登場すると見られる。そうした製品では、例えば、bigを2コア、LITTLEを4コア搭載しているなら、6コアにうまく負荷に合わせたロードバランシングを行なって、パフォーマンスと電力のバランスを取ってCPUコア群を動作させることができるようになるだろう。
また、スケジューラに対する拡張も、できる限り小さく留めようとしているように見える。ロードバランサの拡張で、スケジューラのほかの機構に影響が出ないようにしている。
ARMがbig.LITTLE MPがタスクスケジューラをあまりいじらなかったのは、OSの根幹の1つであるタスクスケジューラの置き換えが高リスクだからだ。ある業界関係者は「カーネルスケジューラを切り替えたら、例えば、Red Hatのサーバーが遅くなりました、といった事態が生じると非常に困る。現在のスケジューラは問題なく動いているので、それと同じレベルの動作が保証されないと難しいだろう」と語る。もちろん、ARMのbig.LITTLE MP開発陣に、これまでLinuxカーネルを開発した人物はいない。
そもそも、これまで、Linuxの歴史でタスクスケジューラのメジャーな変更は過去に2回しか行なわれていない。最初の「Linus Scheduler」から、「O(1) scheduler」、そして現在の「Completely Fair Scheduler(CFS)」までだ。そのため、ARMがいきなりbig.LITTLEのためにタスクスケジューラを入れ替えたいと言っても、合意を得るのは簡単ではないという。
実際、big.LITTLE MPの提案を受けて、パワーアウエアスケジューラがどうあるべきかを議論している中心人物は、LinuxのスケジューラグルであるIngo Molnar氏だ。今後はこうした人物を中心として、統合的なパワーアウエアスケジューラの開発へと進んで行くだろう。