ハイブリッドコア（P-core/E-core）とスケジューラ対応

なぜ「同じコアが並んでいる」前提が崩れるのか

従来のマルチコアスケジューラは、暗黙に全コアが等価だと仮定してきました。ランキューの偏りをタスク数やPELT由来の負荷で測り、混んだコアから空いたコアへ均せば、どのコアでも同じ仕事が同じ速度で片付く——この前提があるからこそロードバランシングは単純な貪欲法で成立していました。

ハイブリッドコアはこの前提を壊します。IntelのP-core（Performance）／E-core（Efficiency）、ARMのbig.LITTLE／DynamIQでは、コアごとに最大周波数・命令幅・キャッシュ容量・電力効率がすべて非対称です。同じスレッドでも、走らせるコア次第でスループットが数倍変わり、消費電力も桁が違います。ここで「タスク数だけ均す」素朴なバランサを適用すると、前景の重いスレッドを省電力コアへ流して体感性能を落とし、逆に軽いバックグラウンドをP-coreへ載せて電力を無駄にします。スケジューラはどのコアかを性能と電力の両面から選ばねばなりません。

容量非対称：CPU capacityという土台

OSが非対称を扱う最初の足場が**CPU capacity（容量）**です。各CPUに正規化した処理能力（Linuxでは最強コアを1024とする相対値）を割り当て、スケジューラはこれを負荷と突き合わせます。E-coreはcapacityが小さいので、同じutil（PELTで追跡する実効使用率）のタスクでもE-core上では相対的に「混んでいる」と評価されます。

capacityを導入すると、バランシングの判定が「タスク数の差」から「capacityに対して負荷が収まっているか」へ変わります。あるCPUの負荷がそのcapacityを超えそうな状態をoverutilizedと呼び、この状態のときはまず性能を優先して空きコアへ散らします。逆にシステム全体が余裕のあるうちは、性能ではなく電力を最小化する配置（後述のEAS）へ切り替えます。容量非対称は、こうした「性能モードと省電力モードの切り替え」の土台になります。

Intel Thread DirectorとITMT

Intelのハイブリッド構成では、コアの非対称に加えて同じスレッドでも処理内容で最適コアが変わるという難しさがあります。整数中心のループとAVXベクトル演算では、P-coreとE-coreの性能差・電力差が一様ではないからです。これをハードウェアが観測してOSへ伝えるのがThread Directorです。

Thread Directorは実行中スレッドのマイクロアーキ的振る舞い（命令ミックスやメモリ挙動）を監視し、スレッドを性能クラスに分類します。そのうえで「このクラスのスレッドにとって、各コアタイプの相対的な性能ヒントと効率ヒントはこれだ」という表をOSへ提供します。OSはコンテキストスイッチのたびにこのヒントを読み、配置の参考にします。重要なのは、これがハードウェアからの助言であってハードウェアが勝手にスレッドを動かすわけではない点です。最終的にどのコアで走らせるかは、あくまでOSスケジューラが決めます。

ヒントを実際の選好へ変換する仕組みがITMT（Intel Turbo Boost Max Technology 3.0）由来の優先コア順序です。OSは各CPUに優先度（asym priority）を持たせ、性能を要するスレッドを高優先のコア——通常はP-core、その中でも個体ばらつきで最も高クロックを出せる「favored core」——から順に割り当てます。

ARM big.LITTLEとEAS（Energy Aware Scheduling）

ARM側のアプローチは消費電力の明示的なモデル化です。SoCは各CPUの周波数ごとの消費電力（およびcapacity）をエネルギーモデル（EM）としてOSへ提供します。スケジューラはこのテーブルを使い、タスクをどのCPUに置くとシステム全体の消費電力がどれだけ増えるかを予測します。これが**EAS（Energy Aware Scheduling）**の核心です。

タスク起床時の配置（select_task_rq）で、EASは候補CPUごとに「そのCPUへ載せたときのutil増分」をエネルギーモデルに通し、追加電力を見積もります。そして性能要件を満たしつつ追加電力が最小になるCPUを選びます。軽いタスクはLITTLE（E-core相当）へ、要求の高いタスクはbigへ、と自然に振り分くのはこの計算の帰結です。

ただしEASが働くのはシステムが overutilized でないときに限られます。どこかのCPUが容量を超えて詰まり始めたら、省電力を考えている余裕はないと判断し、スケジューラはEASを一時停止して通常のcapacity-aware負荷分散（性能優先）へ戻します。EASは「余裕があるうちは賢く省電力、逼迫したら性能優先」という二段構えで、ここが従来の対称マルチコアと最も違う挙動です。

ヒントは命令ではない：誤配置はどこから来るか

両陣営に共通する原則は、ハードウェアやモデルが渡すのはヒント（助言）であって命令ではないことです。最終判断はOSスケジューラが、ヒント・負荷・ランキュー状態・スロットリング状況・NUMA/メモリ局所性まで突き合わせて下します。だからこそ、誤配置の原因はおおむね次のどこかにあります。

• OSがヒントを解釈しない（古いカーネル/ドライバ未対応）ため、コアを等価扱いして前景スレッドがE-coreに残る。
• バランサが容量非対称を無視し、タスク数だけで均してP-coreを空けたままE-coreを詰める。
• overutilizedの判定が遅れ、本来は性能優先に切り替わるべき場面でEASが省電力配置を続けてしまう。
• 短命タスクがヒント確定前に終わり、Thread Directorの観測が間に合わない。

まとめ

• ハイブリッドコアは「全コア等価」という従来バランサの前提を壊す。判断の土台は**CPU capacity（容量非対称）**で、均す指標が「タスク数の差」から「capacityに対して負荷が収まるか」へ変わる。
• IntelはThread Directorがスレッドを性能クラスに分類し、コアタイプ別の性能/効率ヒントをOSへ渡す。OSはITMT由来の優先コア順でP-core（favored core）を選好する。
• ARMはエネルギーモデルを基にEASが各CPUへの配置の追加電力を見積もり、性能要件下で最小コストのCPUを選ぶ。ただしoverutilizedなら性能優先へ自動で切り替わる。
• いずれもHWが渡すのは**ヒント（助言）**で、最終決定はOSスケジューラ。誤配置はOSのヒント未対応・容量非対称を無視した均し・切替判定の遅れから生じる。