省電力スケジューリング（EAS）

EASが解こうとした問題

CFS（/os/cfs-scheduler-internals/）やEEVDF（/os/eevdf-scheduler/）は、CPUが性能的に同質（SMP）であることを前提に「公平さ」を最適化してきました。しかしスマートフォンやタブレットのSoCの多くは big.LITTLE（heterogeneous multi-processing, HMP） 構成を取り、高性能・高消費電力な big コアと、省電力・低性能な LITTLE コアが混在します。同質前提のロードバランシング（/os/cpu-affinity-load-balancing/）だけでは「busyなCPUから暇なCPUへ均す」ことはできても、「このタスクをどのコア種別に置けば消費電力あたりの性能が最良か」という問いには答えられません。

EAS（Energy Aware Scheduling） は、この配置判断にエネルギーという指標を明示的に持ち込みます。目的は単純です。性能要求（デッドライン）を満たせる範囲で、消費電力が最小になるCPUへタスクを置く。バッテリ駆動のモバイル・組込み機器では、同じ処理を終えるにも「どのコアで」「どの周波数で」走らせるかでエネルギー消費が数倍変わり得るため、この最適化は電池持ちに直結します。

エネルギーモデルとutilという2つの材料

EASの判断は2つの入力の突き合わせで成り立ちます。

エネルギーモデル（Energy Model, EM） は、各CPU（正確には周波数ドメイン単位）について「動作周波数（P-state）ごとの消費電力」をテーブルとして保持します。このテーブルはプラットフォームの device tree やファームウェアから登録され、カーネルが実測するものではありません。big コアは高周波数まで伸びる代わりに同じ周波数でも消費電力が高く、LITTLE コアは到達周波数は低いが電力効率が良い、という非対称性がテーブルに表れます。

util（利用率） は /os/cfs-scheduler-internals/ で扱った PELT（Per-Entity Load Tracking）が生成する指標で、タスクが直近どれだけCPUを使っていたかを指数移動平均で表します。util はCPUの実クロックに依存しない正規化値で、「同じタスクを別のCPU capacity（最大性能）を持つコアに置いたら、そのCPUの util はどうなるか」を比例計算で予測できます。

あるタスクのutilをCPU capacityの異なる別コアへ写すとき:

  予測util_on_target = util_on_source * (capacity_source / capacity_target)

  例: LITTLEコア(capacity=512)で util=400 のタスクを
      bigコア(capacity=1024)に置くと予測util = 400 * (512/1024) = 200

この予測が成立するからこそ、EASは「実際に動かしてみる」ことなく、候補CPUごとの見込み負荷を事前に見積もれます。

EASの探索: wakeupに割り込んで最小消費電力を選ぶ

EASは常時全タスクを再配置するわけではありません。介入するのは主に wakeup時のCPU選択（select_task_rq_fairの経路） です。タスクが起床するたびに、EASは候補CPUを絞り込んだうえで、それぞれについて「このタスクを置いたら合計消費電力がどう変わるか」を見積もり、最小になるCPUを選びます。

wakeupしたタスクtに対して:

  候補CPUの集合 = そのタスクのアフィニティで許された、
                  かつ性能を確保できる少数のCPU
                  （全CPUを総当たりはしない）

  各候補CPU cについて:
    そのCPUを含む周波数ドメインの他タスクutilも合算し、
    ドメインが到達する周波数（=そのutilを満たす最小周波数）を求める
    エネルギーモデルからその周波数での消費電力を引く

  合計消費電力が最小のcを選ぶ

ここでの核心は、性能要求を満たす最小のCPU・最小の周波数で収めるという発想です。これは電力管理の原則である race to idle（/os/cpu-power-management/で扱った「早く終えて眠る」発想）と表裏の関係にあり、無駄に速いコアへ置いて早々にアイドルへ戻すより、ちょうど収まる遅いコアで走らせ切る方が総消費電力で有利な場面を拾います。ただし小さいタスクを LITTLE に寄せすぎると、複数の小タスクが1つのコアに積み上がって util が容量を超え、結果的に性能要求を満たせなくなることがあります。EASはこの超過（overutilized状態）を検出すると、その周波数ドメインについてはエネルギー最適化を諦め、通常のロードバランシングに戻して性能を優先します。

CFS/EEVDFとの関係: 置き換えではなく前段の判断

EASはCFSやEEVDFを置き換えるものではありません。どのCPUで走らせるかを決める配置レイヤであり、そのCPU上でいつ走らせるかを決めるのは従来どおりCFS/EEVDFの役割です。EASが選んだCPUのランキューに入った後は、通常の vruntime／lag に基づく選択がそのまま適用されます。

同様に schedutil（/os/cpu-power-management/）とも役割が異なります。schedutilは「選ばれたCPU上でutilに応じて周波数を決める」のに対し、EASは「そもそもどのCPUにutilを置くか」を決めます。両者は同じutil・エネルギーモデルという語彙を共有しつつ、配置と周波数選択という別レイヤで協調します。

まとめ

• EASは big.LITTLE のような非対称CPU構成で、エネルギーモデル（周波数ごとの消費電力表）とutil（PELT由来の利用率予測） を突き合わせ、性能要求を満たしつつ消費電力最小のCPUへタスクを配置する。
• 主に wakeup時のCPU選択 に介入し、候補CPUを絞ったうえで各候補の予測消費電力を比較する。overutilizedになると性能優先の通常経路へ戻る安全弁を持つ。
• CFS/EEVDFを置き換えるものではなく、配置（どのCPU）を決める前段レイヤであり、配置後のCPU内スケジューリングは従来どおり vruntime／lag に委ねられる。
• 同じutil・エネルギーモデルの語彙を schedutil（周波数選択）と共有しつつ、役割は分離されている。モバイル・組込みでバッテリ持続時間を左右する中核機構であり、SMPサーバーでは前提条件を満たさず自動的に休眠する。