當中斷處理程序被另一箇中斷中斷時，中斷上下文如何「恢復」？

（1）從羅伯特·愛：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）從Which context are softirq and tasklet in?

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.

所以，在我的理解，中斷處理程序在中斷上下文中運行，並且無法進入睡眠狀態，也就是說，不能像正常進程那樣執行上下文切換。

但是中斷處理程序可以被另一箇中斷中斷。當第二個中斷處理程序完成其工作時，控制流將跳回第一個中斷處理程序。

如何在沒有正常的上下文切換的情況下實現「恢復」？它是否像正常的函數調用一樣，將所有寄存器和其他相關內容存儲在某個堆棧中？

來源

2013-12-23 feirainy

Robert Love：* ...因爲中斷沒有支持進程context_ *和Softirq/tasklet：*中斷上下文甚至沒有描述註冊信息的**數據結構**。在這兩種情況下，技術描述都是沒有'thread_info'，'task_struct'或'struct mm'。你需要調度一個'task_struct'。中斷等可以在'thread_info'中作爲堆棧內核上下文的*堆棧*。 –

簡短的回答是，一箇中斷處理程序，如果它可以被一箇中斷中斷，就會以與其他中斷相同的方式中斷。

說過程X正在運行。如果進程X中斷，則中斷處理程序運行。在有上下文的情況下，它仍然是X進程，儘管它現在在內核中運行中斷代碼（如果你願意，可以考慮X - >interrupt）。如果發生另一箇中斷，那麼中斷會被中斷，但是仍然沒有特殊的進程上下文。該州現在是X - >first_interrupt - >second_interrupt。當第二個中斷結束時，第一個中斷將恢復，就像第一個中斷完成時X恢復一樣。儘管如此，唯一的過程上下文仍然是進程X.

您可以將它們描述爲上下文切換，但它們不像進程上下文切換。它們更類似於進入和退出內核 - 進程上下文保持不變，但執行級別和代碼單元可以改變。

來源

2013-12-23 06:02:20

因此，像第一個中斷的過程X中斷一樣，第一個中斷處理程序寄存器中的「上下文」在被第二個中斷中斷時存儲在內核堆棧中。 – feirainy

@feirainy確實如此。是。進程上下文被中斷處理程序劫持（或者'借用'），而不是被切換。這使中斷成本保持較低。 –

在進入真實中斷處理程序之前，中斷程序將存儲一些CPU狀態和寄存器，並在返回中斷任務之前恢復這些信息。通常，這種存儲和恢復不稱爲上下文切換，因爲被中斷的進程的上下文沒有改變。

來源

2013-12-23 12:37:02

當中斷處理程序被另一箇中斷中斷時，中斷上下文如何「恢復」？

回答

相關問題