EAS が Google Pixel を最速の Android スマートフォンにするのにどのように貢献するか

いっぱいNov 09, 2023

Google Pixel スマートフォンは、市場で最速の Android スマートフォンの 1 つです。 電話が非常にスムーズである理由の 1 つは、Energy Aware Scheduling (EAS) です。

Linux が Linus Torvalds の頭の中のアイデアにすぎなかったはるか昔、CPU はわずかな電力で膨大な量のエネルギーを必要とするシングルコアのエンティティでした。 史上初の市販プロセッサである Intel 4004 は、シングル コアで 740kHz のクロック レートで動作しました。 当時はロード スケジューラは必要ありませんでした。 負荷スケジューリングは、数十年後に登場した IBM Power 4 などのデュアルコアの「巨人」のために予約されていました。 これらは 1.1 GHz ～ 1.9 GHz という驚異的な速度で動作し、これらのコアを正しく利用するにはプログラムとシステムが必要でした。 これらのマシンから、どのようにして複数のコアを利用するソフトウェア アルゴリズムにたどり着いたのでしょうか? 以前にフォーラムで Energy Aware Scheduling (EAS) について聞いたことがあるかもしれません。 これが、Google Pixel スマートフォンのパフォーマンスが非常に優れている理由の 1 つです。 EAS の何がそんなに優れているのでしょうか? また、どのようにしてこの点に到達したのでしょうか? それを説明する前に、Linux ロード スケジューラについて説明する必要があります。

Linux ロード スケジューラの進化

ラウンドロビンスケジューリング

ラウンドロビン処理。 出典: ウィキペディア

ラウンドロビン処理は、説明して理解するのが簡単な概念であり、その欠点を把握するのがさらに簡単です。 ラウンドロビンでは、タイム スライスを使用して各プロセスに時間を割り当てます。 コンピューター上で 4 つのプロセスが実行されていると仮定します。

  • 工程A
  • 工程B
  • プロセスC
  • プロセスD

ここで、ラウンドロビン スケジューラの仕事をしてみましょう。 次のプロセスに進む前に、各プロセスに 100 ミリ秒 (タイム スライス) を割り当てます。 これは、プロセス A の処理に 100 ミリ秒かかる可能性があり、その後プロセス B に移動する、ということを意味します。 アプリケーションのジョブの実行に 250 ミリ秒かかる場合、その作業を完了するだけでこのプロセスを 3 回実行する必要があります。 これを異なるコア間でスケールし、プロセス A とプロセス B がコア 1 に割り当てられ、プロセス C とプロセス D がコア 2 に割り当てられるようにします。 これは、O(n) スケジューリング (ラウンドロビンに似ていますが、エポックを使用し、 時間)、次に O(1) スケジューリング (最小限のオーバーヘッド、無制限のプロセス サポート)、最後に完全に公平なスケジューラー (CFS)。 CFS は、2007 年 10 月に Linux カーネル バージョン 2.6.23 に統合されました。 その後全面的に見直しが行われ、今でも Linux システムのデフォルトのスケジューラとして使用されています。

完全に公平なスケジューラー

Completely Fair Scheduler は Android の当初から存在しており、それほど大きくないもので使用されています。 小さなデバイス。 インテリジェントなアルゴリズムを使用して、処理順序、割り当て時間などを決定します。 これは、「加重均等キューイング」と呼ばれる、よく研究されたスケジューリング アルゴリズムの実用的な実装例です。 これは基本的に、システム プロセスや、上で実行されているその他の優先度の高いプロセスに優先順位を与えることに重点を置いています。 機械。 それが大きなもので走るとしたら。 LITTLE デバイスでは、すべてのコアが同等であると認識されます。 これは、低電力コアが負荷の高いアプリケーションを実行することを強制される可能性があり、さらに悪いことにその逆が発生する可能性があるため、好ましくありません。 たとえば、音楽を聴くためのデコードがビッグ コアで実行されると、消費電力が不必要に増加する可能性があります。 これが、大規模向けの新しいスケジューラが必要な理由です。 LITTLE は、コアの違いを実際に認識し、電力効率の高い方法で利用できるものです。 そこで、ほとんどの Android スマートフォンで現在実行されている標準の負荷スケジューラであるヘテロジニアス マルチプロセッシング (HMP) が登場します。

異種混合マルチプロセッシング

これは、あらゆる大企業向けの標準的なロード スケジューラです。 Google Pixel以外に近年発売されたLITTLEデバイス。 HMPは大きなものを利用します。 LITTLE アーキテクチャ。優先度が低く、集中力の低い作業を、消費電力の少ない小さなコアに委任します。 HMP は「安全」であり、何を大きなコアに送信し、何を小さなコアに送信すべきかを間違いなく認識しています。 これは問題なく機能し、開発側でのセットアップに必要な労力は、すぐに説明する EAS のようなものよりもはるかに少なくて済みます。 HMP は、電力を考慮した CFS の拡張にすぎません。

HMP は推測を受け付けず、将来のプロセスを予測しません。 これは良いことですが、このデバイスが EAS を実行しているデバイスほど流動的ではない理由であり、バッテリーの消費量が若干多くなる理由でもあります。 最後に、Energy Aware Scheduling (EAS) について説明します。これは、より多くの OEM が採用することで、ROM およびカーネル開発の未来になると私は確信しています。

エネルギーを意識したスケジューリング

Energy Aware Scheduling (EAS) は、フォーラムのユーザーが話題にしている次の大きな話題です。 OnePlus 3 (または Google Pixel) を使用している場合は、フォーラムでそれについて聞いたことがあるでしょう。 Qualcomm Snapdragon 845 で主流になったので、これらのデバイスのいずれかを持っている場合は、すでに EAS 対応スマートフォンを持っていることになります。 次のようなカーネル形式の EAS レンダーゼニス および次のようなROM VertexOS そして ピュアフュージョン 最盛期には OnePlus 3 フォーラムを席巻していました。 もちろん、Google PixelにもEASが搭載されています。 バッテリー寿命の向上とパフォーマンスの向上が約束されていますが、何が問題なのでしょうか?

Energy Aware Scheduling は、CFS や HMP などのすべてのデバイスに共通ではないため、それほど単純ではありません。 EAS では、エネルギー モデルに基づいて、EAS が実行されているプロセッサを理解する必要があります。 これらのエネルギー モデルは、最適なパフォーマンスを提供するために常にテストと作業を行うエンジニアのチームによって作成されています。 Snapdragon 820 と 821 は基本的に同じであるため、OnePlus 3 のカスタム カーネルは Google Pixel エネルギー モデルを使用します。 Snapdragon 845 を搭載したデバイスは EAS を利用でき、OnePlus 6 もある程度は利用できます。 Google Pixel デバイスほど調整されていませんが、十分な機能を備えています。 これは、OnePlus 6 が EAS を備えたより優れたプロセッサを搭載しているにもかかわらず、Pixel 2 XL が滑らかさの点でそれを上回っていることを示す例です。 これらの画像は両方とも当社から取得したものです スピード重視のレビュー OnePlus 6の。

グラフを理解するのが難しい場合は、下の画像を参考にしてください。 緑の線を超えるものはフレームのドロップを示し、最悪の場合は顕著な途切れが発生します。

OnePlus 6 の EAS 実装は興味深いものですが、同じ SoC を搭載した Google Pixel のような本格的な実装ではないようです。 スケジューラの調整パラメータもあまり意味がありません。そのため、期待したほどパフォーマンス効率が良くない理由がおそらくこれにあります。 システムは大部分の作業で低電力コアを優先するため、消費電力は非常に控えめです。

調整パラメータは、CPU ガバナーに渡される単なるパラメーターのセットであり、周波数に関して特定の状況に対してガバナーがどのように反応するかを変更します。 次に、スケジューラは、さまざまなプロセッサ上のどこにタスクを配置するかを決定します。 OnePlus 6 の調整パラメータは、低電力コアでの作業を優先するように設定されています。 また、Google Pixel 2 の入力ブーストが大幅に向上し、8 コアすべてを常にオンラインに保つことも役に立ちません。 Google も使用しています 割り込みバランサ これはフレームドロップを解消し、パフォーマンスを向上させるのに役立ちます。

では、EAS はどのように機能するのでしょうか? なぜ特定の条件下でのみそれほど効率的になるのでしょうか?

Energy Aware Scheduling ではエネルギー モデルを使用する必要があり、前述したように、それを完璧にするためには多くのテストと作業が必要です。 EAS は、すべて独立して動作するカーネルの 3 つの異なるコア部分を統合しようとします。エネルギー モデルは、それらを統合するのに役立ちます。

  • Linux スケジューラ (CFS、前述)
  • Linux CPUアイドル
  • LinuxのCPU周波数

スケジューラの下で 3 つの部分をすべて統合し、それらを一緒に計算すると、それらを一緒に計算することで可能な限り効率が高まるため、エネルギー節約の可能性が得られます。 CPUIdle は、CPU がアイドル モードに移行するタイミングを決定しようとしますが、CPUFreq は、CPU をいつランプアップまたはランプダウンするかを決定しようとします。 これらのモジュールは両方とも、エネルギーを節約することが主な目的です。 それだけでなく、プロセスをトップアプリ、システムバックグラウンド、フォアグラウンド、バックグラウンドの 4 つの cgroup に分類します。 処理されるタスクはこれらのカテゴリのいずれかに分類され、そのカテゴリに CPU パワーが与えられ、作業はさまざまな CPU コアに委任されます。 top-app は完了の優先順位が最も高く、次にフォアグラウンド、バックグラウンド、system-background と続きます。 バックグラウンドは技術的にはシステム バックグラウンドと同じ優先順位を持っていますが、通常、システム バックグラウンドはより小さなコアにもアクセスできます。 実際、Energy Aware Scheduling は Linux カーネルのコア部分を取り出し、すべてを 1 つのプロセスに統合します。

デバイスをウェイクアップするとき、EAS は最も浅いアイドル状態のコアを選択し、デバイスのウェイクアップに必要なエネルギーを最小限に抑えます。 これにより、必要がなければ大規模なクラスターがウェイクアップされないため、デバイスの使用時に必要な電力が削減されます。 負荷追跡も EAS の非常に重要な部分であり、2 つのオプションがあります。 通常、「エンティティごとの負荷追跡」(PELT) は負荷追跡に使用され、その情報は頻度と CPU 全体でタスクを委任する方法を決定するために使用されます。 「Window-Assisted Load Tracking」（WALT）も使用でき、これは Google Pixel で使用されているものです。 VertexOS など、フォーラム上の多くの EAS ROM は WALT の使用を選択しています。 多くの ROM では、WALT または PELT を使用した 2 つのバージョンのカーネルがリリースされるため、決定はユーザー次第です。 WALT はよりバースト性が高く、CPU 周波数のピークが高くなりますが、PELT はより一貫性を維持しようとします。 負荷トラッカーは実際には CPU 周波数に影響を与えず、CPU 使用率がどの程度であるかをシステムに伝えるだけです。 CPU 使用率が高くなると、より高い周波数が必要となるため、PELT の一貫した特性として、CPU 周波数がゆっくりと上昇または下降することが挙げられます。 PELT は、より高い CPU 負荷レポートに偏る傾向があるため、より高いバッテリーコストでより高いパフォーマンスを提供する可能性があります。 ただし、どちらの負荷追跡方法も継続的にパッチが適用され、改良されているため、現時点ではどちらの負荷追跡システムが優れているとは言えません。

いずれにせよ、使用される負荷追跡方法に関係なく、効率が向上することは明らかです。 プロセッサーでタスクを単に処理するのではなく、タスクが分析され、その実行に必要なエネルギー量が推定されます。 この賢いタスク配置により、タスクがより効率的に完了すると同時に、システム全体の速度も向上します。 EAS は、最小限の電力使用量で可能な限りスムーズな UI を実現することを目的としています。 ここで、schedtune などの他の外部コンポーネントが活躍します。

Schedtune は、完了するタスクをより細かく制御できる 2 つの調整パラメータによって各 cgroup で定義されます。 複数の CPU にわたるタスクの分散を制御するだけでなく、時間に敏感なタスクをより早く完了するために、認識される負荷を増大させる必要があるかどうかも制御します。 こうすることで、ユーザーが利用しているフォアグラウンドのアプリケーションやサービスの速度が低下したり、不要なパフォーマンスの問題が発生したりすることがなくなります。

Energy Aware Scheduling は次の目玉ですが、すでに存在しており、しばらく前から存在していると主張することもできます。 Energy Aware Scheduling を搭載したデバイスがますます主流となり、モバイル処理効率の新時代が到来しています。

ラウンドロビン、CFS、HMP、EAS の長所と短所

私のグラフィックススキルは標準以下ですが、これらのスケジューラーのそれぞれの長所と短所を要約した画像を作成しました。

XDA 認定貢献者に特別な感謝の意を表したいと思います。 モスタファ・ワエル EAS のさまざまな側面についての彼の説明は、この記事の作成に大いに役立ちました。 XDA 認定開発者にも感謝します。 陽気な、XDA 認定開発者 レンダリング壊れた そして Mostafa Wael 氏、EAS に関する寄稿. EAS 関連の部分に興味を持った方のために、Linaro には EAS に関する多くのドキュメントが用意されており、読むことができます。