Linux カーネル割り込みハンドラーの下位半分について初めて読んだところです。延期された作業のための作業キューの使用を理解しようとしています。
私が理解していることから、softirps やタスクレットに対する作業キューの利点は、作業がプロセス コンテキストで実行されるため、スリープできることです。しかし、デフォルトでは、この作業はイベント/X スレッドの 1 つで順次行われますか? そのため、events/0 で何らかの作業が開始され、その後何らかの IO を待機して長時間スリープ状態になると、そのプロセッサでこれ以上作業キュー アイテムを処理できなくなり、パフォーマンスが大幅に低下します。
作業が長時間スリープ状態になる可能性がある場合、すべての割り込みハンドラー開発者がデフォルトのイベント/X スレッドを使用しないという責任はありますか? それとも私は何かを誤解していますか？
しかし、デフォルトでは、この作業はイベント/X スレッドの 1 つで順次行われますか? そのため、events/0 で何らかの作業が開始され、その後何らかの IO を待機して長時間スリープ状態になると、そのプロセッサでこれ以上作業キュー アイテムを処理できなくなり、パフォーマンスが大幅に低下します。
これは正確ではありません。workqueue API では、シングルスレッド タスクとマルチスレッド タスクの両方が可能です。前者の場合、関数 create_singlethread_workqueue() が呼び出されます。
作業が長時間スリープ状態になる可能性がある場合、すべての割り込みハンドラー開発者がデフォルトのイベント/X スレッドを使用しないという責任はありますか? それとも私は何かを誤解していますか？
softirq (つまり、タスクレット) では、まったくスリープできないため、基本的に、ワークキューの利点はスリープできることです。実際、シングルスレッドのワークキューの場合に他の kthreads を飢えさせないようにすることは開発者の責任です。
また、workqueue API は、タスクのエンキュー/デキュー以上のものを提供するだけでなく、遅延作業のキューイング、作業間の同期、作業キューのフラッシュ、遅延作業のキャンセルなどの機能も提供することに注意してください。この API は、他の API よりも優れています。非スリープ可能な使用法であっても、softirq ベースのライブラリ。