私はいくつかの関連する投稿を読みました：
（1）Robert Loveから：http：//permalink.gmane.org/gmane.linux.kernel.kernelnewbies/1791
You cannot sleep in an interrupt handler because interrupts do not have a backing
process context, and thus there is nothing to reschedule back into. In other
words, interrupt handlers are not associated with a task, so there is nothing to
"put to sleep" and (more importantly) "nothing to wake up". They must run
atomically.
（2）softirqとtaskletはどのコンテキストからですか？
If sleep is allowed, then the linux cannot schedule them and finally cause a
kernel panic with a dequeue_task error. The interrupt context does not even
have a data structure describing the register info, so they can never be scheduled
by linux. If it is designed to have that structure and can be scheduled, the
performance for interrupt handling process will be effected.
したがって、私の理解では、割り込みハンドラーは割り込みコンテキストで実行され、スリープできません。つまり、通常のプロセスがバッキングメカニズムで行うように、コンテキストスイッチを実行できません。
ただし、割り込みハンドラは別の割り込みによって中断される可能性があります。そして、2番目の割り込みハンドラーがその作業を終了すると、制御フローは最初の割り込みハンドラーにジャンプして戻ります。
この「復元」は、通常のコンテキストスイッチなしでどのように実装されますか？すべてのレジスタと他の関連するものが特定のスタックに格納されている通常の関数呼び出しのようなものですか？
簡単に言うと、割り込みハンドラーは、割り込みによって割り込まれる可能性がある場合、他のものが割り込みによって割り込まれるのとまったく同じ方法で割り込まれます。
プロセスXが実行されているとします。プロセスXが中断されると、割り込みハンドラーが実行されます。コンテキストがある限り、それはまだプロセスXですが、カーネルで割り込みコードを実行しています（必要に応じて、状態をX->と考えてinterruptください）。別の割り込みが発生すると、割り込みは中断されますが、特別なプロセスコンテキストはありません。状態はX-> first_interrupt->になりましたsecond_interrupt。2番目の割り込みが終了すると、最初の割り込みが終了したときにXが再開するのと同じように、最初の割り込みが再開します。それでも、唯一のプロセスコンテキストはプロセスXです。
これらはコンテキストスイッチとして説明できますが、プロセスコンテキストスイッチとは異なります。これらは、カーネルの開始と終了に似ています。プロセスコンテキストは同じままですが、実行レベルとコードの単位は変更される可能性があります。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加