コラム

CTC教育サービス・ホーム　＞　コラム　＞　グーグルのクラウドを支えるテクノロジー　＞　第118回　ユーザースペースのプラグイン型タスクスケジューラー「ghOSt」（パート2）

グーグルのクラウドを支えるテクノロジー

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第118回　ユーザースペースのプラグイン型タスクスケジューラー「ghOSt」（パート2） (中井悦司) 2021年12月

はじめに

　前回に続いて、2021年に公開された論文「ghOSt: Fast and Flexible User-Space Delegation of Linux Scheduling」を元にして、Googleのエンジニアが開発したプラグイン型のタスクスケジューラ「ghOSt」を紹介します。今回は、Linuxカーネルとユーザー空間のエージェントの通信方法を中心としたアーキテクチャの詳細を説明します。

Linuxカーネルとエージェント間の通信方法

　前回の図1に示したように、Linuxカーネルは、メッセージキューを用いて、ユーザー空間のエージェントに通知を行います。一方、エージェントからLinuxカーネルへの通知には、システムコールが用いられます。図1は、Linuxカーネルから送られるメッセージの種類と、エージェントが使用するシステムコールの一覧になります。

fig01

図1 ghOStが使用するメッセージとシステムコール（論文より抜粋）

　ここで用いられるメッセージキューは独自に実装されたもので、管理対象のプロセスごとに個別のキューが用意されます。前回の図2で説明した「Enclave」ごとにデフォルトのキューが用意されており、新たなプロセスがghOStの管理対象になると、まずはデフォルトのキューが割り当てられます。その後、エージェントは、図1に示したシステムコール（CREATE_QUEUE、ASSOCIATE_QUEUE）を用いて、新たなキューを作成して、こちらを該当のプロセスに割り当て直します。
　CPUコアごとにスケジューリングを行う「per-CPUモデル」（1つのEnclaveに1つのCPUだけを含む設定）の場合、Linuxカーネルは、新たなメッセージをキューに投入すると、対応するエージェントを実行状態に変更します。その後、エージェントはキューのメッセージを読み出して、プロセスのスケジューリング処理を行い、その結果をシステムコールでカーネルに通知します。また、プロセスを実行するCPUコアを変更する際は、システムコールを用いて、該当のプロセスに対応するキューを別のCPUコアに割り当て直します。
　一方、Enclaveを用いて複数のCPUコアをグループ化した場合は、動作が異なります。この場合は、複数のCPUコアに対するスケジューリングをまとめて行うため、エージェントは定期的なポーリング処理を行い、すべてのキューからのメッセージをまとめて取得します。スケジューリング処理の結果を複数のCPUコアに通知する際は、それぞれのCPUコアに対するスケジューリング結果を共有メモリーに書き込んだ後に、コミット処理のシステムコール（TXNS_COMMIT）を実行することで、スケジューリング結果が確定します。CPUコアごとにシステムコールを実行する必要がなく、スケジューリングに必要なシステムコールの実行回数を減らすことができます。
　図2は、エージェントのスケジューリング処理の実装例で、メッセージキューからのメッセージの取得、スケジューリング結果を通知するトランザクションの作成、複数のトランザクションの一括コミット（27行目）という流れが確認できます。また、何らかの理由でトランザクションに失敗してスケジューリングができなかった場合の例外処理も行われています。

fig02

図2 エージェントのスケジューリング処理の実装例（論文より抜粋）

性能向上の工夫

　複数のCPUコアをグループ化してスケジューリングを行う場合、個々のCPUコアから見ると、スケジューリングが確定するまでの時間は「per-CPUモデル」よりも長くなります。特に、スケジューリングが確定するまでの待ち時間中に、CPUコアがアイドル状態（実行可能なプロセスがない状態）になると、CPUコアの実行時間が無駄になります。この問題を回避するために、ghOStでは、LinuxのBPFと呼ばれる機能を利用します。BPFは、ユーザー空間のプロセスが登録したコードをカーネル空間で安全に実行する機能で、ghOStのスケジューリングポリシーから、BPFで実行するコードを登録します。CPUコアがアイドルになったタイミングでこのコードが実行されるようになっており、スケジューリングが未確定の場合は、このタイミングで該当のCPUコアで実行するべきプロセスを確定させることができます。
　また、複数のCPUコアをグループ化する場合は、前回の図2（右）に示したように、それぞれのCPUコアにエージェントが割り当てられますが、その中の1つ（グローバルエージェント）が実際のスケジューリング処理を行います。このエージェントは定期的なポーリング処理を行うため、常に実行状態を保つ必要があります。しかしながら、グローバルエージェントを実行中のCPUコアに対して、ghOStの管理対象外のプライオリティの高いプロセスが割り当てられたり、定期実行が必要なカーネルスレッドが割り当てられることがあります。このような場合、グローバルエージェントは、他のCPUコアに割り当てられたエージェントに処理を引き継いだ後に、他のプロセスやカーネルスレッドにCPUコアを空け渡します。

次回予告

　今回は、2021年に公開された論文「ghOSt: Fast and Flexible User-Space Delegation of Linux Scheduling」を元にして、Googleのエンジニアが開発したプラグイン型のタスクスケジューラ「ghOSt」について、Linuxカーネルとユーザー空間のエージェントの通信方法を中心としたアーキテクチャの詳細を説明しました。次回は、実環境におけるghOStの性能を示すベンチマークデータを紹介したいと思います。

Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡