Linux schedule（）何时返回？

在阻塞IO的情况下，例如，驱动程序读取，我们调用wait\u event\u interruptable（），并附带一些条件。当条件满足时，将进行读取。 我研究了wait\u event\u interruptable（）函数，它检查条件并调用schedule（）。schedule（）将查找下一个可运行的进程，并进行上下文切换，其他进程将运行。这是否意味着，当此进程再次被唤醒时，当前进程要执行的下一条指令将在schedule（）函数中

如果是，如果多个进程自愿调用schedule，那么所有进程在唤醒后都将有下一条要执行的指令，这条指令将完全在schedule（）内

在ret_from_中断的情况下，调用schedule（）。它什么时候回来？因为iret是在那之后执行的

---

我认为第一个问题的答案是是，因为这是实现上下文切换的一种相当典型的方式，比如说

---

如果从ISR调用调度程序，则所有内容都应相同。调度程序应更改上下文并返回到ISR，然后ISR应使用

IRET

返回。如果调度程序选择切换到另一个进程/线程，它将返回到另一个进程/线程，并因此加载其上下文并保存旧的进程/线程。

Re第2点：执行

iret

指令（从中断处理程序返回），从而进入

ret\u from\u interrupt

。然后Linux将控制权传递给下一个要运行的任务（

schedule（）

）。在编写中断处理程序时，最重要的考虑因素之一是，当它们执行许多其他活动时，它们会被禁止（其他的、优先级较低的中断是主要的例子），因此您希望尽快离开那里。这就是为什么大多数中断处理程序在返回之前都会把要完成的工作隐藏起来，然后说这些工作会在其他地方处理（今天在一些特殊的内核线程中）。

感谢您的回复。从代码中我看到，在do_IRQ调用之后，common_中断从_intr跳到ret_。从ret_From_intr我们点击resume_内核，从那里它调用preempt_schedule_irq（），只有当我们点击restore_时，所有更早或更晚的iret才会被执行。我遗漏了什么吗？谢谢你的回复。在这里，我无法理解schedule（）如何返回到中断上下文？由于它不是作为任何进程运行的，因此中断上下文本身并不多，它是当前进程线程上下文的一部分，中断发生在线程上下文中。看见阅读相关章节。