问题调度程序代码在什么上下文中运行？

调度程序代码有两种情况 schedule() 被援引 -

当一个进程自愿调用时 schedule()
定时器中断调用 schedule()

在案例2中，我认为 schedule() 在中断环境中运行，但第一种情况呢？它是在调用它的进程的上下文中运行的吗？

还有更多的场景可以调用 schedule()？

6571

2017-08-18 10:37

起源

还有一种情况是调用schedule（）：进程阻塞时（例如由于I / O操作）。 - omer

@omer当进程阻塞时调用schedule（）的定时器中断。所以你的情况与案例2相同 - baotiao

答案:

schedule() 始终在流程上下文中运行。在第二种情况下，当它由定时器中断启动时，它处于从内核返回到中断进程的返回路径中 schedule() 叫做。

2017-08-18 11:14

好的schedule（）作为系统调用发生，这只是一个陷阱中断AFAIK对吗？ - Jesus Ramos

@Jesus Ramos：“进程上下文”和“中断上下文”是Linux内核开发术语，用于描述在内核空间中执行的代码的上下文：是否可以将其视为代表特定进程执行（如在系统调用中））或替代地为硬件中断服务。 - caf

是的，我知道这个术语是因为系统调用在技术上是一个中断，所以我不确定这是他的意思还是调用实际执行的方式。 - Jesus Ramos

@Jesus Ramos：对内核的输入方式进行分类是没有意义的，因为它是总是通过某种形式的中断进入。 schedule() 本身总是代表要调度的进程执行的代码路径，即使内核是通过定时器中断输入的 - 这意味着进程上下文。 - caf

@JesusRamos：无论如何，传统（非英特尔）术语将是：中断（来自设备），陷阱/系统调用（来自软件），异常/错误（任何前者+来自CPU）。英特尔将是：异常/故障（来自CPU），中断（来自任何地方）。 - ninjalj

__schedule（）是主调度函数。

驱动调度程序并因此进入此功能的主要方法是：

显式阻塞：互斥，信号量，等待等等
在中断和用户空间返回路径上检查TIF_NEED_RESCHED标志。例如，请参阅arch / x86 / entry_64.S。为了驱动任务之间的抢占，调度程序在计时器中断处理程序scheduler_tick（）中设置标志。
唤醒并不会导致进入计划（）。他们将一个任务添加到运行队列中就是这样。现在，如果添加到运行队列的新任务抢占当前任务，则唤醒设置TIF_NEED_RESCHED并在最近的可能情况下调用schedule（）：
- 如果内核是可抢占的（CONFIG_PREEMPT = y）：
  - 在系统调用或异常上下文中，在下一个最前面的preempt_enable（）中。（这可能是wake_up（）的spin_unlock（）！）
  - 在IRQ上下文中，从中断处理程序返回到可抢占上下文
- 如果内核不可抢占（未设置CONFIG_PREEMPT），那么在下一个：
  - cond_resched（）调用
  - 显式schedule（）调用
  - 从系统调用或异常返回到用户空间
  - 从中断处理程序返回到用户空间

http://lxr.free-electrons.com/source/kernel/sched/core.c#L2389

2017-09-04 20:19

进程调用时 schedule() 它运行在基于中断的系统调用上下文中。在第二种情况下，硬件中断触发 schedule() 呼叫。在这两种情况下，它都作为中断运行。 AFAIK是唯一一次 schedule() 之所以被调用是因为大多数调度操作涉及修改要调度的事物的内核运行队列，尽管过程可以被中断但通常通过中断来告诉过程产生或过程产生自身。

2017-08-18 10:47

问题 调度程序代码在什么上下文中运行？

答案:

热门问题

问题调度程序代码在什么上下文中运行？