Windows Server 2008 R2 (および Windows 7) の CPU 関連のアーキテクチャ


こんにちは。

Windows Server 2008 R2 についての話です。

この OS、開発者にとって大変メリットが大きく、例えば Server Core で .NET アプリなども稼働可能、さらにコマンドラインの機能が各段に充実 (例 : PowerShell V2、リモーティング、DISM、など) していることから、周辺の開発環境(クライアント) からコマンドラインベースの Server Core に対して開発/デバッグ/運用管理をおこなうといったシナリオにも対応しています。もちろん、開発の話ばかりではなく、エバンジェリストの高添 がブログ/セミナーでもご紹介している Live Migration (停止せずに仮想マシンを移動できる Hyper-V 2.0 の新機能) などは、開発者の皆さんにとっても大きなメリットでしょう。

さて、その心臓部ですが、Windows 7 と同一のカーネルを使用し、64 bit アーキテクチャのみの対応となっています (Windows 7 のほうは 32 ビットも OK ですが、32 bit 環境では、ここで述べる UMS などは使用できません)。パフォーマンス向上、最大で 256 論理プロセッサに対応、それでも省エネ ! と、化け物的な「基本性能」も売りの 1 つです。
この Windows Server 2008 R2 をフル活用した実装は、さながら超高級なハード/OS一体型の専用サーバー機をホウフツとさせるような芯の太さです。

以下のドキュメントでも R2 の魅力について書いていますが、この冒頭でも 「最新の CPU アーキテクチャ (例 : SLAT 等のハードウェアアーキテクチャ) を認識」、「改善されたメモリ管理」 などその基本性能の向上を大きくうたっています。

ダウンロードセンター : Windows Server 2008 R2 にアップグレードする 10 の理由:
http://download.microsoft.com/download/D/D/1/DD187274-7AF3-45FA-BA2D-C7033F097C66/Top_10_Reasons_to_Upgrade_to_WS08R2.doc

今回は、この OS が持っている CPU アーキテクチャの進化っていったい何なの ? という点について概略を記載しましょう。

ユーザーモードスケジューラー (UMS, User Mode Scheduler) 

(2009/08/12 追記 : ここは、エバンジェリスト岩田が、バッチリ説明してくれています
http://blogs.msdn.com/masaki/archive/2009/08/12/windows-7-ums-user-mode-scheduler.aspx)

CPU 利用時における Block (I/O 操作時、ヒープ割り当て時、などに頻繁に発生) の問題を回避するため、新しい UMS というスレッドのスケジューリングの仕組みが提供されています。

この UMS では、複数のユーザーモードスレッドと、対応する複数のカーネルモードスレッドを管理しています。
実行中のコアでブロックが発生すると、カーネルモードでその内容が検知され、待機中の別のスレッドを実行します (実行中であったユーザーモードスレッドは待機状態になります)。このように、コアを可能な限り効率的に使用していきます。
スレッドの実行開始時にまず実行されるのはユーザーモードスレッドです。UMS では、システムコールの呼び出しがおこなわれた場合だけ対応するカーネルモードスレッドにコンテキストが変更されるので、ユーザーモードスレッドの切り替えをおこなうたびに毎回カーネルモードでの切り替えがおこなわれることはありません 。(つまり、軽量に動作します。)
待機していたスレッドのカーネルモードでのブロックが解除されると、対応するユーザーモードスレッドは Completion List に登録されて、コアで実行中のスレッドが終了するのを待って再び実行されます。

従来の OS のスケジューラーでは、長時間の処理と、ブロックされた処理の区別ができず、このため、他のタスクの実行がしばしば待たされることがありました。また、データベースなどで使用されていた従来の「ファイバー」のテクノロジーでは、ユーザーモードでの動作が可能 (つまり、軽量) ですが、カーネルモードの状態を検知することはできませんでした。
この新しい UMS では、ブロックをカーネルモードで検知し、切り替えをユーザーモードで実施することが可能です。つまり、軽量で、かつマルチコアシステムにおいても効率的に動作することができます (コアを可能な限りブロックすることなく稼働します)。

TechDays などに参加されていた方はご存じかと思いますが、次期開発環境である Visual Studio 2010 には、並列プログラミングをサポートするためのライブラリが提供されます。そのライブラリのベースとして Concurrency Runtime (ConcRT) という基盤が提供されますが、Concurrency Runtime ではこの UMS を内部で使用しています。つまり、マネージスレッドを生成して並列処理をおこなう従来の実装方法と比べ、新しい専用ライブラリを使用した実装では破格のパフォーマンス差で並列処理をおこなうことが可能です。

Non-Uniform Memory Access  (NUMA) の活用 

複数のプロセッサにおけるメモリ, ディスクのアクセスにおいては、バスなどにおける競合が頻繁に発生することになります。例えば、すべての CPU が同一の物理メモリにアクセスにいく場合、せっかく並列にプロセッサが動作をしても、メモリアクセスでブロッキングが頻繁に発生することになるでしょう。この結果、あるレベルまではコアの数に応じて線形のパフォーマンス向上が期待できますが、最終的にはこのボトルネックによりパフォーマンスはフラット化するでしょう。

こうした点を解決するのが NUMA です。新しい Windows Server 2008 R2 のカーネルは、この NUMA を強く意識して設計されており、CPUの「グループ化」の概念を使ってこうした状況を OS も一緒になって軽減します。
Windows Server 2008 R2 におけるこのプロセッサのグループ化は、カーネルにより決定されます。1 つの論理プロセッサ (1 スレッドを処理するコアの場合には、「コア」=「論理プロセッサ」ということになります) は、必ずどこか 1 つのグループに属します。さらに、例えば、同一コアの中の論理プロセッサ、同一の物理プロセッサ内のコア、物理的に近い論理プロセッサなど、近傍の論理プロセッサどうしが同一のグループに振り分けられます。
これにより、上述のようなオーバーヘッドを低減させることが可能になります。(以下に動作イメージを図示します)

Windows Server 2008 R2 のデフォルトの動作では、単一スレッド (Windowsのスレッド) は、必ず、単一グループを対象に動作し、単一プロセス (Windowsのプロセス) は 64 bit アフィニティを使用した複数グループに割り当てて動作させます。(NUMA システム API 関数を使用して、開発者が、アフィニティの取得や設定をおこなうこともできます。)

NUMA を意識したこの新しい動作については、下記の MoreThan64proc.docx に記載されています。

http://www.microsoft.com/whdc/system/Sysinternals/MoreThan64proc.mspx

コアパーキング (Core Parking) 

プロセッサには、Execute, Halt, Sleep などの P-State (Processor State) と呼ばれる状態を持っていますが (注意 : ここに記載している「状態」はあくまでも例示であり、一般に、もっとこ細かく状態がわかれています)、新しい Windows は、パワーマネージメント用タイマーでこの状態の管理をおこなっています。
この管理では、マシン全体のワークロードが低い場合にソケット (CPU ソケット) の電力を節約できるよう、特定のアルゴリズムに従って、どの処理をどのコアで処理するかを決定しています。そして、ソケット上のコアがすべてアイドル状態になると、そのソケットのパワーを節約 (セーブ) します。

 

この他に、タイマーイベントをタイマーの tick (きざみ) の周期と同期させることでタイマーによる中断を減少させる仕組み (Timer Coalescing) や、外部のトリガ (例 : 特定のデバイスインタフェースが使用された際、など) に応じて Windows サービスを起動/停止することで普段は余計なリソースを使用しない 「Triger-Start サービス」 (UBPS = Unified Background Process Manager と呼ばれる機構が使用されています) など、プロセスのオーバーヘッドを軽減したり、起動速度を向上させるための仕組みが数多く実装されています。

Windows 7 / Windows Server 2008 R2 のカーネルではさまざまなチューニングがおこなわれていますが、こうした 64 bit ならでは、という仕組みもいくつか存在しています。(特に、「サーバー」では重要な要素です、、、)

 

Skip to main content