linux-kernel - ユーザー空間アプリケーションでのタスクレットの利点

Question

下半分に疑問があります。ここでは、タスクレットのみを考えます。また、プリエンプティブルでないカーネルのみを考慮します。

rx 割り込み処理が約 10 個の関数呼び出しを実行しているイーサネット ドライバを考えてみます。(悪いプログラミング :))

ここで、タスクレットに 9 つの関数呼び出しを移動でき、割り込み処理で呼び出す必要があるのは 1 つだけである場合のパフォーマンスの観点を見ると、tcp 読み取りアプリケーションで本当に良いパフォーマンスを得ることができますか?

言い換えると、ユーザー空間アプリケーションへの切り替えがあると、スケジュールされたタスクレットの 9 つの関数呼び出しがすべて呼び出され、実質的に、ユーザー空間アプリケーションは「スケジュールされたすべてのタスクセット」が終了した後にのみパケット兼データを取得できるようになります。完了？正しい？

下半分を使用することで、すべての割り込みを有効にしていることは理解しています..しかし、割り込みに依存するアプリケーションが、割り込みハンドラー自体または下半分に10個の関数全体を配置することで、実際に何かを得るかどうかは疑問です。

つまり、タスクレットを使用することで、ユーザー空間アプリケーションのパフォーマンスが向上しますか?

Answer 1

タスクレットはキューに入れられるのではなくスケジュールされるため、同じタスクレットをポストする複数のハードウェア割り込みが 1 つのタスクレット関数の呼び出しになる可能性があるため、極端なケースでは 最大 90%の処理を​​節約できます。

一方、net-rx には優先度の高いソフト IRQ が既に存在します。

Answer 2

タスクレットは、ユーザー プロセスのコンテキストでは実行されません。ISR がタスクレットをスケジュールする場合、タスクレットは isr が完了した直後に実行されますが、割り込みが有効になっています。これの利点は、パケット処理が追加の割り込みを妨げないことです。

TCPの例では、ハードウェアがパケットをネットワークスタックに渡し、ドライバーが完了します-ネットスタックはプロセスの起動などを処理するため、データのプロセスコンテキストでハードウェアのドライバーを実行する方法は実際にはありませんハードウェアはそれが誰であるかさえ知らないためです。

Answer 3

高速マシンでの私の経験では、作業をハンドラーからタスクレットに移動しても、マシンの実行速度は向上しません。schedule_tasklet() 呼び出しをタスクレット関数自体の呼び出しに変えることができるマクロをハンドラーに追加しました。両方の方法でベンチマークを行い、違いを確認するのは簡単です。

ただし、割り込みハンドラが迅速に終了することが重要です。Nikolai が述べたように、デバイスが多くの割り込みを好む場合はメリットがあるかもしれませんが、ほとんどの高帯域幅デバイスには割り込み軽減ハードウェアがあり、これがそれほど深刻な問題ではありません.

タスクレットを使用することは、コア カーネルの人々が行う方法であるため、他のすべてが同じであれば、特にメインライン カーネルに受け入れられるドライバーを見たい場合は、彼らの先導に従うのがおそらく最善です。

また、多くの関数を呼び出すことは必ずしも悪い習慣ではないことにも注意してください。最新の分岐予測子を使用すると、分岐の多いコードを分岐の少ないコードと同じくらい高速に実行できます。私の意見では、それよりもはるかに重要なのは、現在半分の作業を実行し、後で半分の作業を行う必要があるという潜在的なキャッシュ効果です。