プロセス間の切り替え (並行して実行するのではなく、実際に切り替えることを前提としています)。
ユーザー空間からカーネル空間へのトラップは、以前はプロセッサ割り込みで行われていました。2005 年頃 (カーネルのバージョンは忘れてください)、メーリング リストでの議論の後、ハイエンドの xeon プロセッサでは以前の Pentium II または III よりもトラッピングが遅い(絶対的な測定で!) ことがわかりました (再び、私の記憶)、彼らは新しい cpu 命令でそれを実装しましたsysenter(これは Pentium Pro から実際に存在していたと思います)。これは、各プロセスの Virtual Dynamic Shared Object (vdso) ページで行われます (cat /proc/pid/maps で検索) IIRC。
そのため、現在、カーネル トラップは基本的にほんの数回の CPU 命令であり、割り込みを使用する場合の 10 分の 1 または 10 万分の 1 (最新の CPU では非常に遅い) と比較して、かなり少ないサイクルです。
プロセス間のコンテキスト スイッチは重いです。これは、すべてのプロセッサの状態 (レジスタなど) を RAM に格納することを意味します (実際には、ユーザー プロセス空間の魔法のメモリ位置で、どこにあるかを推測してください!)、実際には、CPU にキャッシュされたすべてのメモリをダーティにし、新しいプロセスのプロセス状態を読み戻します。処理する。(おそらく) 最後に実行したときの CPU キャッシュにはまだ何もないため、各メモリ読み取りはキャッシュ ミスになり、RAM から読み取る必要があります。これはかなり遅いです。私が大学にいたとき、私は「発明」しました (まあ、私は CPU にたくさんのダイがあることを知っていましたが、常に電力が供給されていると十分な冷却が得られないことを知っていました)、電力は供給されていませんが無限のサイズであるキャッシュを「発明」しました。 CPU で未使用 (つまり、コンテキスト スイッチでのみ使用) の場合、これを Simics に実装します。Linux で CARD (Context-switch Active, Run-time Drowsy) と呼ばれるこの魔法のキャッシュのサポートを実装し、かなり厳密にベンチマークしました。同じコアを共有する多くの重いプロセスを持つ Linux マシンを約 5% 高速化できることがわかりました。ただし、これは比較的短い (低レイテンシーの) プロセス タイム スライスでした。
ともかく。コンテキスト スイッチは依然としてかなり重いですが、カーネル トラップは基本的に無料です。
各プロセスについて、ユーザー空間のどのメモリ位置にあるのか答えてください:
アドレス ゼロ。そう、ヌルポインタです！とにかく、ユーザー空間からこのページ全体を読み取ることはできません:)これは2005年にさかのぼりますが、CPU状態情報がページサイズよりも大きくならない限り、現在もおそらく同じです。その場合、実装が変更された可能性があります.