当初、私はコードを高速化するために、カーネルとユーザー空間の間の遷移を減らし、より多くのコードをカーネルで実行するようにプッシュする方がよいと考えていました。ただし、SO のようないくつかのフォーラムで、実際には逆のことが行われていることを読みました。より多くのコードがユーザー空間にプッシュされます。どうしてこれなの？直感に反するようですか？より多くのコードをユーザー空間に配置するには、カーネルからユーザーへの遷移が必要ですが、コードをカーネルに配置してもカーネルからユーザーへの遷移は必要ありませんか?
誰かが尋ねた場合に備えて、パケットデータを処理するアプリケーションについて考えています。
編集
詳細については、パケットデータがいつ到着するかについて考えています-ネットワークスタックを書き直し、パケット処理に適用できないコードを切り取り、コピーをゼロにしたい-パケットデータをユーザープログラムができる場所に配置しますできるだけ早くアクセスしてください。
カーネルは時間に敏感な領域であり、ISR、タイム ティック ルーチン、およびハードウェア クリティカル セクションが存在する場所です。このため、目的は、カーネル コードを小さくタイトに保ち、入り込み、作業を完了し、抜け出すことです。
あなたの場合、ネットワークからパケットを取得しています。これはハードウェアに依存するタスクです (ネットワークの下位層からデータを取得する必要があります)。データを取得し、バッファをクリアし、DMA 転送を介してユーザー空間に送信します。次に、ユーザー空間で処理を行います。
私の経験から:カーネルでコードを実行することによって得られるパフォーマンスは、カーネルでより多くのコードを実行することによって全体的に失われるパフォーマンスを上回ることはありません。
コードが公式のカーネル リリースに組み込まれることを期待している場合、「そのコードのユーザー モード部分をカーネルにシャッフルする」ことは、原則としておそらく悪い考えです。
もちろん、そうすることがより良いパフォーマンスを達成するための最良の (主観的な、私が知っている) 方法であり、コストが許容できることを証明できれば (カーネルの余分なコードの観点から -> カーネルのメンテナンスの負担が大きくなり、カーネル -> カーネルが「大きすぎる」などの苦情が増えるなど)、その場合は必ずそのルートに従ってください。
しかし、一般的には、ユーザーモードでより多くの作業を行うことでこれにアプローチし、カーネルモードのタスクを小さくすることをお勧めします。カーネルで何をしているか、ユーザーモードで何をしているかを正確に知らなければ、何をすべきか/すべきでないかを確実に言うのは困難です。ただし、たとえば、カーネルが何かを実行するための 1 つの要求であるブロックにダースの「アイテム」をバッチ処理することは、カーネルをダース回呼び出すよりも優れたオプションです。
あなたがしていることを説明するあなたの編集に応じて:データを受信するためにユーザーモードのメモリ領域を渡してから、パケットが到着したときにそこにコピーする方が良いのではないでしょうか。「すべてのメモリが等しい」と仮定すると [そうでない場合は、とにかく「その場での使用」に問題があります]、これはカーネルで費やす時間が少なくても同様に機能するはずです。