問題タブ [context-switch]

keventdのプロセスを考えてみましょう。カーネルモードで一生を費やします。さて、私が知る限り、プロセスがカーネルモードからユーザーモードに切り替わる間、Linuxはコンテキストスイッチが必要かどうかをチェックします。私が知る限り、keventdはカーネルモードからユーザーモードに切り替わることはありません。 Linuxカーネルはいつスイッチを切るかを知っていますか？

ユーザープロセスがシステムコールを実行すると、カーネルプロセスが呼び出されます。では、これによってコンテキストスイッチが発生しないのはなぜですか？カーネルプロセスはユーザープロセスとは異なるため。または、カーネルルーチン（システムコールによって呼び出される）とユーザープロセスが同じプロセスに属していると言っているのは間違っていますか？

すでに質問されているのに、この質問をするのは申し訳ありませんが、明確にすることができませんでした。したがって、システムコール（モードスイッチ）とコンテキストスイッチの違いを理解するために、次の関連する質問をしています

• 呼び出しを行っているプロセスのコンテキストを保存してから再ロードする必要がある場合、システム コールにコンテキスト スイッチが必要ないと言われるのはなぜですか。コンテキストスイッチの定義によれば、別のプロセスに切り替える必要があるという理由だけですか。

• システムコールが行われると、カーネルが「ユーザーコンテキスト」で実行されるとはどういう意味ですか?

• ウィキペディアの記事によると: http://en.wikipedia.org/wiki/Context_switch

システム コールにコンテキスト スイッチは必要ありませんが、オペレーティング システムに依存し、システム コール中にコンテキスト スイッチが発生する場合があります。システムコール時にコンテキストスイッチが発生した場合はどうなるのだろうか。例はありますか？

プロセスの自発的および非自発的なコンテキストスイッチをカウントするために、システムコールを実行する必要があります。Linuxカーネルに新しいシステムコールを追加する手順はすでに知っていますが、コンテキストスイッチ関数をどこから始めればよいかわかりません。何か案が？

コンテキスト切り替えを行うための呼び出し規約が何であったかは重要ですか。AMD64 と同様に、最初の 4 つのパラメーターはレジスターなどを介して渡されます。

コンテキスト切り替えシステムは、これらの詳細について心配する必要がありますか?

割り込み処理について読んだ（そして勉強した）。
私がいつも理解していないのは、割り込みハンドラーから（PC / IP）に戻る場所をどのように知るかです。
私が理解しているように：

1. 割り込みはデバイス（キーボードなど）によって引き起こされます
2. 関連するハンドラーは、実行中のプロセスの下で呼び出されます。つまり、OSへのコンテキストスイッチは実行されません。
3. 割り込みハンドラーが終了し、実行中のアプリケーションに制御を戻します。

上記のプロセスは、割り込み処理についての私の理解であり、現在実行中のプロセスのコンテキスト内で実行されます。つまり、コンテキストスイッチではなく、メソッド呼び出しに似ています。
ただし、実際には割り込みハンドラーに対してCALLを実行しなかったため、現在のIPをスタックにプッシュする機会がありませんでした。
では、割り込みからジャンプして戻る場所をどのようにして知ることができますか。よくわかりません。

この質問に具体的に対処する優れたpdf/pptを単に指し示すワンライナーを含め、説明をいただければ幸いです。
[私は一般的にLinuxとCコードの下で上記のプロセスを参照していますが、すべての良い答えを歓迎します]

block(thread)a の実行を停止した場合thread、どのように、どこで、いつ戻るのでしょうか?

次の割り込みを有効にするスレッドはどれWait()ですか? thread呼び出された は、block()別のスレッドが呼び出されるまで返されるべきではありませんwakeup(thread)!

• しかし、その他のスレッドはどのように実行されるのでしょうか?
• スレッドの切り替えは正確にどこで行われますか?

プロセスが実行中の場合、PCBの内容(カーネル メモリ空間にありますか?) が CPU レジスタ、ステータス レジスタ、カーネル スタック ポインタ、ユーザー スタック ポインタなどにロードされます。

別のプロセスへのコンテキスト切り替えがあると、現在の「コンテキスト」が PCB に保存され、新しい PCB への切り替えが行われます。

カーネルがこの PCB を「コンテキスト」に戻したい場合、現在メモリ内にあるこの PCB をどのように見つけるのでしょうか? カーネルがメモリ内の PCB を見つけるのに役立つ情報は何ですか?

コンテキストスイッチに関するインラインアセンブリ命令について別の質問があります。このコードは機能するかもしれませんが、100％かどうかわからないので、このコードをstackoverflowのプロに送信します;-)

arm7TDMIにgcc（最適化なし）を使用してコンパイルしています。ある時点で、コードはコンテキスト切り替えを実行する必要があります。

コンパイルされたコードを確認すると、次の結果が得られます。

これをコーディングした私の前の人は「lrを保存する必要があります」と書いていますが、コンパイルされたコードでは、lrが保存されている痕跡は見当たりません。

コードが間違っている可能性があると思う理由は、リセット例外が発生する前にプログラムがしばらく実行され、コードが最後に実行するのはコンテキストスイッチであるためです...

プロセススイッチがあり、新しいプロセスのページテーブルとページディレクトリを使用する必要がある場合、カーネルはどこから新しいプロセスのページディレクトリの場所を知るようになりますか？

新しいプロセスのページディレクトリが物理メモリに保存されていることを知っています。しかし、カーネルはどのようにしてそれを見つける場所を知るのでしょうか？