Linuxコンテキストスイッチの内部：プロセスがタイマー割り込みの前に終了するとどうなりますか？

Question

タイマ割り込み前にプロセスが終了すると、Linuxカーネルでコンテキストスイッチはどのように行われますか？

フラグが設定されている場合は、schedule関数が自動的に呼び出され、実行する次のプロセスが選択されていることがわかります。基本的にこの場合、スケジュール関数は現在のプロセスのコンテキストで実行されますが、タイマー割り込み前でもプロセスが終了するとどうなりますか？この場合はscheduleと電話をかけますか？そして、それはどんな文脈で実行されますか？

Answer 1

タイマ割り込みは、scheduleが呼び出される数百の異なる理由の1つにすぎないことを理解することが重要です。実行時間が計算に支配されているプログラムは、思っていたよりも稀であり、タイムスライスを使い果たしてしまいます。プログラムが数マイクロ秒（マイクロ秒）で実行されるのは、システムコールの「ブロッキング」とユーザーの入力を待つこととの間で、一度に数マイクロ秒で実行する方がずっと一般的です。

プロセスが何らかの方法で終了すると、そのプロセスの（カーネル）コンテキストで最終的にdo_exitへの呼び出しが行われます。 do_exitは最後のアクションとしてscheduleを呼び出し、scheduleは決してそのコンテキストに戻りません。ちょうどdo_exitの最後にscheduleへの呼び出しがあり、すぐにBUG();と無限ループが続くことに注意してください。

はこの直前に、do_exit親プロセスにSIGCHLDを送信および/またはwaitへの呼び出しから、それを解除するための責任がある、exit_notifyを呼び出します。したがって、多くの場合、scheduleが呼び出されると、親プロセスが実行準備完了になり、選択されます。誰かがwaitを呼び出すまで

do_exitもtask_struct自体を、ユーザ空間の状態のすべてのプロセスに関連付けられているカーネルの状態の多くの割り当てを解除するメモリを解放し、ファイルディスクリプタをクローズする、などが生き残るしなければならない、と私は理解できませんカーネルがどのように割り当て解除できるかを正確にどのように決定するか。このコードは複雑すぎます。

プロセスは_exitを呼び出した場合は、カーネルの呼び出しチェーンは、単にsys_exit_groupdo_group_exitにdo_exitにあります。致命的な同期信号（例：SIGSEGV）が発生した場合、コールチェーンはかなり長くなり、その中に厄介な転用があります。ハードウェアトラップは、アーキテクチャ固有のコード（例えば、x86 do_trap）によってforce_sig_infoとsend_signal~complete_signalとの間でフィールド化され、タスク状態を調整し、スケジューラに問題のプロセスを起こさせる。原因となっているプロセスが目を覚ますと、アーキテクチャー固有のシグナル処理ロジックの迷路によって、最終的にget_signalに転送され、do_group_exitが呼び出され、do_exitが呼び出されます。致命的な非同期信号（例えば、シェル・プロンプトでkill 12345を入力してから）sys_killで開始し、すべてが上記のように進行するの後、send_signalにkill_something_info、group_send_sig_info、do_send_sig_info経ます。どちらの場合も、complete_signalまでのすべてのステップは、のプロセスコンテキスト内で発生することがありますが、そのプロセスのコンテキストでは「プロセスが起きる」の後のすべてが発生します。

Linux固有のこの説明の唯一の部分は、カーネルのコード内の関数の名前です。Unixの実装には、Linuxのdo_exitとscheduleのような機能を果たすカーネル機能があり、偽の同期信号と致命的な非同期信号の両方に似た動作シーケンスが認識可能に似ています。