Windowsシングルコア

Windowsは最も多面的で柔軟なOSの1つであり、まったく異なるアーキテクチャで動作し、さまざまなバージョンで利用できます。 現在、x86、x64、ARM、およびARM64アーキテクチャをサポートしています。 Windows はかつて Itanium、PowerPC、DEC Alpha、MIPSをサポートしていました。 さらに、Windowsはさまざまな条件下で動作する幅広いSKUをサポートしています。 データセンター、ラップトップ、Xbox、電話から、ATMなどのモノのインターネットの組み込みバージョンまで。

最も驚くべき側面は、WindowsカーネルがこれらのアーキテクチャとSKUのすべてに依存して実質的に変化しないということです。 カーネルは、それが機能するアーキテクチャとプロセッサに応じて動的にスケーリングし、機器を最大限に活用します。 もちろん、カーネルには特定のアーキテクチャに関連付けられた一定量のコードがありますが、そこには最小限のコードしかなく、さまざまなアーキテクチャでWindowsを実行できます。

この記事では、 Surface RT 2012で実行される低電力NVidia TegraチップからAzureデータセンターで実行される巨大なモンスターに透過的に拡張できるWindowsカーネルの主要部分の進化について説明します。


1792個の論理プロセッサと2 TBのメモリをサポートする896個のコアを備えた、Windows DataCenterクラスのプレリリースマシンで実行されるWindowsタスクマネージャー

シングルコアの進化

Windowsカーネルの詳細について説明する前に、 リファクタリングについて少し説明しましょう。 リファクタリングは、さまざまなSKUおよびプラットフォーム（クライアント、サーバー、電話など）でのOSコンポーネントの再利用を増やす上で重要な役割を果たします。 リファクタリングの基本的な考え方は、異なるSKUで同じDLLを再利用できるようにすることで、DLLの名前を変更したり、アプリケーションの作業を中断したりすることなく、目的のSKU専用の小さな変更をサポートします。

Windowsリファクタリングのコアテクノロジーは、 APIセットと呼ばれる、ほとんど文書化されていないテクノロジーです。 APIスイートは、OSがDLLとその使用場所を分離できるようにするメカニズムです。 たとえば、すべてのAPIの実装が別のDLLで記述されているにもかかわらず、APIセットにより、win32のアプリケーションはkernel32.dllを引き続き使用できます。 これらの実装DLLもSKUによって異なる場合があります。 kernel32.dllなどの従来のWindows DLLで依存性トラバーサルを実行することにより、APIセットの動作を確認できます。


システムがコードの再利用と共有を最大化できるようにするWindowsの構造についての余談を終えたら、OSのスケーリングの鍵であるスケジューラーに従ってカーネルを開始する技術的な深さに移りましょう。

カーネルコンポーネント

実際、Windows NTは、実行可能なレイヤー（Executiveレイヤー、Ex）を使用してすべての高レベルのポリシーを実行する機能の限定されたセットを持つ独自のコアカーネル（KE）を持っているという意味で、 マイクロカーネルです。 EXは依然としてカーネルモードであるため、厳密にはマイクロカーネルではありません。 カーネルは、スレッドのディスパッチ、プロセッサ間の同期、ハードウェアレベルの例外の処理、低レベルのハードウェア依存機能の実装を担当します。 EXレイヤーには、通常コアと見なされる一連の機能を提供するさまざまなサブシステム（IO、オブジェクトマネージャー、メモリマネージャー、プロセスサブシステムなど）が含まれています。


コンポーネントのサイズをよりよく理解するために、カーネルソースツリーのいくつかの主要なディレクトリ（コメントを含む）にあるコード行数のおおよその内訳を以下に示します。 この表には、カーネルに関連するすべてのものがまだ含まれていません。

カーネルサブシステム	コードの行
メモリマネージャー	501,000
登録	211,000
力	238,000
エグゼクティブ	157,000
セキュリティ	135,000
カーネル	339,000
プロセスサブシステム	116,000

Windowsアーキテクチャの詳細については、 Windows Internalsブックシリーズを参照してください。

プランナー

このように地面を準備したので、スケジューラ、その進化、およびWindowsカーネルが非常に多くのプロセッサを備えたさまざまなアーキテクチャにどのように拡張できるかについて少しお話しましょう。

スレッドは、プログラムコードを実行する基本単位であり、Windowsスケジューラが計画するのはまさにその作業です。 開始するスレッドを決定するとき、スケジューラーは優先順位を使用します。理論的には、優先順位の低いスレッドに時間が残っていない場合でも、システム上で優先順位が最も高いスレッドを開始する必要があります。

クォンタム時間（スレッドが動作できる最小時間）を処理すると、スレッドは動的優先度が低下するため、優先度の高いスレッドは永久に動作できなくなります。 別のスレッドが動作するように起動すると、待機の原因となったイベントの重要度に基づいて計算された優先順位が与えられます（たとえば、フロントエンドユーザーインターフェイスの優先順位は大幅に高くなり、I / O操作を完了することはあまりありません）。 したがって、スレッドは、対話型である限り、高い優先度で動作します。 主に計算（CPUバウンド）に接続されると、優先度が低下し、優先度の高い他のスレッドがプロセッサ時間を獲得した後に戻ります。 さらに、カーネルは、特定の期間にプロセッサ時間を受け取っていない既製のスレッドの優先度を勝手に上げて、計算の枯渇を防ぎ、優先度の反転を修正します。

Windowsスケジューラには最初に1つの準備キューがあり、そこから次に優先度の高い実行スレッドを選択しました。 ただし、増加するプロセッサ数のサポートが開始されると、唯一のキューがボトルネックになり、スケジューラはWindows Server 2003リリース領域の作業を変更し、プロセッサごとに1つの準備キューを編成しました。 1つのプロセッサで複数の要求をサポートするように切り替えたときに、すべてのキューを保護する単一のグローバルロックを行わず、スケジューラがローカルの最適値に基づいて決定を行うことができました。 これは、システム内の任意の時点で最高の優先度を持つスレッドが1つあることを意味しますが、リスト内の最高の優先度のスレッドのN（Nはプロセッサの数）がシステムで動作することを必ずしも意味しません。 このアプローチは、Windowsがラップトップやタブレットなどの低電力CPUへの切り替えを開始するまで成功しました。 優先度が最も高いスレッドがそのようなシステムで機能しなかった場合（たとえば、ユーザーインターフェイスのフロントエンドスレッド）、インターフェイスの顕著な不具合が発生しました。 したがって、Windows 8.1では、スケジューラはハイブリッドモデルに転送され、このプロセッサに関連付けられたスレッドの各プロセッサのキューと、すべてのプロセッサの既製プロセスの共有キューが使用されました。 これは、スケジューラアーキテクチャの他の変更（たとえば、ディスパッチャデータベースロックのリファクタリング）により、パフォーマンスに大きな影響を与えることはありませんでした。

Windows 7では、ダイナミックフェアシェアスケジューラ（Dynamic Fair Share Scheduler、DFSS）などが導入されました。 これは主にターミナルサーバーに関するものです。 この機能は、CPU負荷が高い1つのターミナルセッションが他のターミナルセッションのスレッドに影響を与える可能性があるという問題を解決しようとしました。 スケジューラーはセッションを考慮せず、フローを配布するために単に優先順位を使用したため、異なるセッションのユーザーは、フローを絞って他のセッションのユーザーの作業に影響を与える可能性があります。 また、多数のスレッドを持つセッション（およびユーザー）に不公平な利点をもたらしました。これは、多数のスレッドを持つセッションがプロセッサー時間を取得する機会が増えたためです。 スケジューラーにルールを追加する試みが行われました。これにより、各セッションはプロセッサー時間の観点から他のセッションと同等の立場にあると見なされました。 Linuxにも、完全に正直なスケジューラ（ 完全に公平なスケジューラ ）を備えた同様の機能があります。 Windows 8では、この概念はスケジューラグループとして一般化され、スケジューラに追加されました。その結果、各セッションは独立したグループに分類されました。 スレッドの優先度に加えて、スケジューラはスケジューラグループを第2レベルのインデックスとして使用し、次に起動するスレッドを決定します。 ターミナルサーバーでは、すべてのスケジューラグループの重みが同じであるため、スケジューラグループ内のスレッドの数や優先順位に関係なく、すべてのセッションが同じ量のプロセッサ時間を受け取ります。 さらに、このようなグループは、プロセスをより正確に制御するためにも使用されます。 Windows 8では、ジョブ時間の管理をサポートするためにジョブオブジェクトが強化されました。 特別なAPIを使用すると、ソフト制限またはハード制限の場合にプロセスが使用できるプロセッサ時間を決定し、プロセスがこれらの制限に達したときに通知を受け取ることができます。 これは、Linux上のcgroupでのリソース管理に似ています。

Windows 7以降、Windows Serverは、単一のコンピューター上で64を超える論理プロセッサーのサポートを導入しました。 非常に多くのプロセッサにサポートを追加するために、システムに「プロセッサグループ」という新しいカテゴリが導入されました。 グループは、64個以下の論理プロセッサーの不変のセットであり、スケジューラーによって計算単位と見なされます。 ブート時のカーネルは、どのプロセッサがどのグループに属するかを決定します。64プロセッサコア未満のマシンの場合、このアプローチはほとんど認識できません。 1つのプロセスをいくつかのグループ（SQLサーバーのインスタンスなど）に分割できます。一度に1つのスレッドを実行できるのは、同じグループ内だけです。

しかし、CPUコアの数が64を超えるマシンでは、Windowsが新しいボトルネックを示し始め、これにより、SQLサーバーなどの要求の厳しいアプリケーションが、プロセッサコアの数の増加に比例してスケーリングできなくなりました。 そのため、新しいコアとメモリを追加しても、速度の測定値に大きな増加は見られませんでした。 これに関連する主な問題の1つは、ディスパッチャベースのブロックに関する論争でした。 ディスパッチャデータベースをロックすると、作業を計画する必要があるオブジェクトへのアクセスが保護されました。 これらのオブジェクトには、スレッド、タイマー、入力/出力ポート、待機の対象となる他のカーネルオブジェクト（イベント、セマフォ、ミューテックス）があります。 このような問題を解決する必要性からのプレッシャーの下、Windows 7では、ディスパッチャーデータベースのブロックを排除し、オブジェクトごとのロックなど、より正確な調整に置き換える作業が行われました。 これにより、SQL TPC-Cなどのパフォーマンス測定により、一部の構成で以前のスキーマと比較して290％の速度向上が実証されました。 これは、単一の機能の変更が原因で発生したWindows史上最大のパフォーマンス向上の1つでした。

Windows 10は、CPUセットを導入することにより、別の革新をもたらしました。 CPUセットを使用すると、プロセスでシステムを分割し、プロセスを複数のプロセッサグループに分散して、他のプロセスがそれらを使用できないようにすることができます。 Windowsカーネルでは、セットに含まれるプロセッサをデバイスの割り込みが使用することさえ許可されていません。 これにより、アプリケーションのグループに対して発行されたプロセッサ上でデバイスでさえコードを実行できなくなります。 ローテク仮想マシンのように見えます。 これが強力な機能であることは明らかであるため、アプリケーション開発者がAPIを操作するときに大きな間違いをしないように、多くのセキュリティ対策が組み込まれています。 CPUセットの機能は、ゲームモードで使用されます。

最後に、 Windows 10に登場した ARM64をサポートするようになりました。 ARMアーキテクチャは、本質的に異種のbig.LITTLEアーキテクチャをサポートします。「大きい」コアは高速で多くのエネルギーを消費し、「小さい」コアは低速で消費が少ないです。 アイデアは、重要でないタスクを小さなコアで実行できるため、バッテリーを節約できるということです。 big.LITTLEアーキテクチャをサポートし、ARMでWindows 10を実行するときにバッテリー寿命を延ばすために、big.LITTLEアーキテクチャで動作するアプリケーションの要望を考慮して、異種レイアウトサポートがスケジューラに追加されました。

希望により、Windowsはアプリケーションに高品質のサービスを提供し、フォアグラウンド（またはCPU時間を欠くスレッド）で実行されているスレッドを追跡し、「大」コアでの実行を保証しようとしています。 すべてのバックグラウンドタスク、サービス、およびその他の補助スレッドは、小さなコアで実行されます。 また、プログラムでは、スレッドを小さなコアで動作させるために、スレッドの重要性が低いことに強制的に注意することができます。

他の誰かに代わって作業する[Work on Behalf]：Windowsでは、フォアグラウンドでの多くの作業がバックグラウンドで動作する他のサービスによって実行されます。 たとえば、Outlookで検索する場合、検索自体はインデクサーバックグラウンドサービスによって実行されます。 すべてのサービスを小さなコアで実行するだけでは、フォアグラウンドのアプリケーションの品質と速度が低下します。 そのような作業シナリオの下でbig.LITTLEアーキテクチャの速度が低下するのを防ぐために、Windowsは、他のプロセスに代わって作業を実行するために、他のプロセスに着信するアプリケーション呼び出しを監視します。 この場合、サービスに関連するスレッドにフォアグラウンドの優先順位を付け、大きなコアで実行するように強制します。

Windowsカーネルに関するこの最初の記事で、スケジューラの概要を説明します。 OSの内部動作に関する同様の技術的詳細を含む記事は、後に続きます。