問題タブ [preemption]

タスクを切り替えるときにカーネルを更新して、さらに多くのことを行いたいと考えています。そのためには、各切り替えの理由を見つける必要があります。

まず、現在のタスクよりも優先度の高いタスクがあり、それらを切り替える必要がある場合に schedule() が呼び出される関数が見つかりません。どこで発生しますか?

第二に、タスクが終了したり、何かを待機したりするのではなく、CPU を解放する理由はありますか? 利回り関数か何かがありますか？

ありがとう！

以下のプログラムには、timer開始コマンドが続くオブジェクト定義が含まれています。その後、プログラムは他のステートメントの実行を続けます。

私の質問は、TimerFcn正確に0.01秒後に呼び出されるのか、それともタイマー コールバック関数が起動するまで for ループが完了するまで待機するのかということです。

非プリエンプティブ スレッドについて読んでいて、プリンストン大学のスライドを見つけました。次の図が示されています。 pdf )

私が理解したことから、実行されるスレッドは最初に準備完了キューに入れられます。キューからポップすると、実行中の状態になります。別のスレッドを呼び出したい場合は、yield 関数を呼び出します。これにより、スレッドの現在の状態が保存され、キューの末尾に挿入されます。そして、キューの先頭にあるスレッドが実行されます。

スレッドがブロックされた場合 (つまり、何らかのリソースを待機している場合) はどうなりますか? 非プリエンプティブ スレッドでは、リソースを待機してから実行を続行すると考えました。

しかし、下の図からは、ブロックされた状態になり、準備完了キューに入れられているように見えますか? 何故ですか？

spin_lock_irqsaveローカル割り込みを無効にした後、プリエンプションを無効にする必要があるのはなぜですか。

プリエンプションは、割り込みが有効になっている場合にのみ可能であるべきです。したがって、割り込みを無効にした後のプリエンプションについて心配する必要はありません。

プリエンプティブルな Linux カーネルで、スケジューラまたは一部の重要なカーネル スレッドをプリエンプトできますか? 割り込みハンドラ (上半分または下半分) ではどうですか?

同じ優先度を持つプリエンプティブではない定期的なタスクのスケジューリング可能性を決定しようとします。私は次の質問を見つけました:非プリエンプティブ 最早締め切り 最初のスケジューリング、ただし、タスクは定期的ではありませんでした。問題は、定期的なタスクがより高いスケジューリング可能性の境界を取得できるかどうかです。

( LWNの記事より)

RCU 更新操作は、各 CPU がコンテキストを切り替えたことをアサートするために synchronize_rcu() を実行するため、各 RCU リーダーはそのジョブを完了しました。しかし、RCU はリーダーが横取りされないことに依存しなければなりません。実際、LWN は次のように述べています。

この単純なアプローチは、RCU 読み取り側クリティカル セクション全体でプリエンプションが無効になっているカーネル、つまり、CONFIG_PREEMPT および CONFIG_PREEMPT 以外のカーネルでは機能しますが、CONFIG_PREEMPT_RT リアルタイム (-rt) カーネルでは機能しません。

非 CONFIG_PREEMPT カーネルではプリエンプションが無効になっていることは理解していますが、なぜCONFIG_PREEMPTカーネルでも問題ないのでしょうか?