多くの場合、アプリケーションがモードスイッチを作成するため、つまり、ユーザーモードからカーネルモードに移行し、システムコールを実行した後、再びモード切り替え。
私の質問は、モード スイッチのオーバーヘッドはどのくらいですか? CPU キャッシュが無効になったり、tlb エントリがフラッシュされたりしますか?それとも何が原因でオーバーヘッドが発生しますか?
コンテキストの切り替えではなく、モードの切り替えに伴うオーバーヘッドについて質問していることに注意してください。モード スイッチとコンテキスト スイッチは 2 つの異なるものであり、コンテキスト スイッチに関連するオーバーヘッドについては十分に認識していますが、理解できないのは、モード スイッチによってどのようなオーバーヘッドが発生するかということです。
可能であれば、Linux、FreeBSD、Solaris などの特定の *nix プラットフォームに関する情報を提供してください。
よろしく
ラリ
x86 CPU でモード切り替えを行う方法はたくさんあります (ここではそれを想定しています)。関数と呼ばれるユーザーの場合、通常の方法は、タスク ジャンプまたは呼び出し (タスク ゲートおよびコール ゲートと呼ばれます) を実行することです。これらはどちらも、タスク スイッチ (コンテキスト スイッチと同等) を伴います。これに、呼び出し前の処理、呼び出し後の標準的な検証、およびリターンを追加します。これにより、最低限のセーフ モード スイッチが切り上げられます。
Eric のタイミングに関しては、私は Linux の専門家ではありませんが、私が扱ったほとんどの OS では、単純なシステム コールは (安全に実行できる場合) データをユーザー空間にキャッシュして、このオーバーヘッドを回避します。そして、getuid() がそのようなデータ キャッシングの最有力候補になるように私には思えます。したがって、Eric のタイミングは、何よりもユーザー空間での切り替え前の処理のオーバーヘッドを反映している可能性があります。