グーグル M:N スレッド モデルの動作を保証するために必要なコンポーネントの実装を含むパッチの最初のセットを Linux カーネルに含めます。 Googleの取り組みは密室で開発されたAPIの公開に関連している Linux カーネル用。M:N スレッド モデルを使用して、ユーザー空間に実装されたマルチスレッド サブシステムの操作を提供します。 このサブシステムは、遅延を最小限に抑える必要があるサービスの運用を保証するために Google によって使用されます。 スレッド分散のスケジューリングと管理は完全にユーザー空間で実行され、システム コールの実行を最小限に抑えることでコンテキスト切り替え操作の数を大幅に削減できます。
Linux カーネル レベルで指定されたサブシステムの動作を保証するために、SwitchTo API が実装され、待機、再開、スワップ (切り替え) という XNUMX つの基本操作が提供されました。 カーネルに組み込むために、新しい FUTEX_SWAP 操作のコードが提案されており、これを補足します。 、ユーザー空間でマルチスレッド ライブラリを作成するためのフレームワークを提供します。 FUTEX_SWAP は、RPC と同様に、タスク間でメッセージを転送するために使用することもできます。 たとえば、現在タスク間でメッセージを転送するには、FUTEX_WAIT と FUTEX_WAKE を少なくとも 5 回呼び出す必要がありますが、FUTEX_SWAP を使用すると 10 回の操作で済み、XNUMX ～ XNUMX 倍早く完了します。
現在、主に 1:1 および N:1 のフロー モデルが実際に使用されています。 1:1 モデルは以下で使用されます。 (POSIX スレッド) および これは、ユーザー空間のスレッドをカーネル レベルのスレッド (実行スケジューリングの単位) に直接マッピングすることを意味します。 モデル N:1 に実装 は、スレッドのディスパッチをユーザー空間にもたらし、カーネルがユーザー スレッドを認識しなくても、ユーザー空間の N 個のスレッドをカーネル内の XNUMX つのスレッドに結び付けることができます。
1:1 モデルの主な欠点は、カーネルとユーザー空間の間のコンテキスト切り替えのオーバーヘッドが大きいことです。 N:1 モデルはこの問題を解決しますが、新たな問題を生み出します。カーネル内のスレッドは実行スケジューリングの分割不可能な単位であるため、オペレーティング システム カーネル内の XNUMX つのスレッドに関連付けられたユーザー スレッドは、CPU コア間で拡張できず、最終的に CPU コアに関連付けられてしまいます。単一の CPU コア。
M:N モデルはハイブリッドであり、ユーザー空間の N スレッドを OS カーネルの M スレッドにマッピングすることで、上記の欠点をすべて解消します。これにより、コンテキスト切り替えのオーバーヘッドを削減し、CPU コア全体でのスケーリングを確実に行うことができます。 このオプションの代償として、ユーザー空間でのスレッド スケジューラの実装が非常に複雑になり、カーネル スケジューラとアクションを調整するメカニズムが必要になります。
出所： オープンネット.ru