2

私は、Linux カーネル 2.6.36 で同時実行管理されたワークキューを扱っています。しかし、いくつかのフラグについて混乱しています。

  • WQ_HIGHPRI
  • WQ_UNBOUND
  • WQ_RESCUER
  • WQ_CPU_INTENSIVE

フラグWQ_HIGHPRIを付けてワークキューを作成し、いくつかのワークアイテム (w1 w2 w3 w4 など) をキューに入れますが、4 つのワークアイテムはどれもスリープしません。

  1. 4 つの作業項目が同じスレッドによって実行されているかどうか、およびこの状況でスレッドが作成されているかどうか。

  2. 上記の状況で、 を使用すると違いはありますWQ_UNBOUNDか? を設定WQ_UNBOUNDすると、カーネルが を設定するためですWQ_HIGHPRI。

前もって感謝します。

4

1 に答える 1

1

次の抜粋では、Linux カーネルのワークキュー設計の基本について説明しています。

元の wq 実装では、各 wq が独自の個別のワーカー プールを維持していました。MT wq は CPU ごとに 1 つの実行コンテキストしか提供できませんが、ST wq はシステム全体に 1 つしか提供できません。ワークアイテムは、さまざまな問題につながる非常に限られた実行コンテキストで競合する必要がありました。

関数の非同期実行を容易にするために、新しい抽象化である作業項目が導入されました。

作業項目は、非同期で実行される関数へのポインターを保持する単純な構造体です。ドライバーまたはサブシステムが関数を非同期で実行する必要がある場合は常に、その関数を指す作業項目を設定し、その作業項目を作業キューにキューに入れる必要があります。

ワーカー スレッドと呼ばれる特殊な目的のスレッドは、関数をキューから順番に実行します。作業がキューに入れられていない場合、ワーカー スレッドはアイドル状態になります。これらのワーカー スレッドは、いわゆるスレッド プールで管理されます。

これらの問題を解消するために、Concurrency Managed Workqueue (cmwq) フレームワークが開発されました。名前が示すように、最大​​限の並行性を提供することに重点が置かれています。つまり、可能な限り最小限のオーバーヘッドでワークアイテムのブロックを最小限に抑えます。

さまざまな「WQ_*」フラグ

1.WQ_HIGHPRI

  • 優先度の高いワークキューの作業項目は、ナイス レベルが高いワーカー スレッドを含む優先度の高いスレッド プールのキューに入れられます。通常のスレッド プールと高優先度のスレッド プールは相互にやり取りしません。それぞれが個別のワーカー プールを維持し、ワーカー間の同時実行管理を実装します。

2.WQ_UNBOUND

  • ワークキューの同時実行管理には参加しません。作業項目は特定の CPU にバインドされず、使用可能な任意の CPU で実行するようにスケジュールできます。また、必要に応じて追加のワーカー スレッドを起動することもできます。

3.WQ_RESCUER

  • 非推奨 (最新のカーネル)。に置き換えられましたWQ_MEM_RECLAIM。詳細については、この回答をお読みください。

4.WQ_CPU_INTENSIVE

  • ワークキューの同時実行管理には参加しません。代わりに、他のタスクと同様に、CPU スケジューラの責任です。

各フラグの詳細な説明と現在のワークキュー設計の背後にある哲学は、Linux-kernel-src/Documentation/workqueue.txt にあります。

上記の情報を念頭に置いて、クエリへの回答は次のとおりです。

  1. 4 つの作業項目はすべて、特定の CPU にバインドされた優先度の高いスレッドでキューに入れられます。

  2. を使用WQ_UNBOUNDすると、使用可能な任意の CPU でワークアイテムを複数の実行にわたって実行できます。

于 2013-08-06T03:32:16.583 に答える