Linux kernel 调度器的实现是否需要某种硬件支持？

进程在任何给定时间的状态都由正在执行的进程组成，对吗？所以现在假设有4个用户空间程序在处理器上运行。现在，在每个时间片之后，我假设控制必须传递给调度程序，以便下一步可以调度适当的进程。是什么引发了控制权的转移？对我来说，似乎硬件中必须有某种特殊的计时器/寄存器来记录进程占用的当前时间，因为进程本身没有机制来跟踪它执行的时间。。。我的直觉正确吗？

首先，这个答案只涉及x86架构

有不同种类的调度器：抢占式和非抢占式（协作式）

抢占式调度程序抢占进程的执行，即使用TSS（任务状态段）启动上下文切换，然后执行到另一进程的跳转。进程停止，另一个进程启动

协作调度程序不停止进程。它们依赖于进程，进程放弃CPU而支持调度器，也称为“屈服”，类似于没有内核支持的用户级线程

抢占可以通过两种方式实现：作为某些I/O绑定操作的结果，或者在CPU运行时。
假设您向FPU发送了一些指令。它需要一段时间才能完成。在FPU执行计算时，您可以做一些其他事情，而不是无所事事地坐着！因此，作为I/O操作的结果，调度程序切换到另一个进程，可能在FPU完成后立即使用抢占进程恢复。
然而，正如许多调度算法所要求的那样，常规抢占只能在某些中断机制以一定频率发生时实现，而与进程无关。计时器芯片被认为是合适的，1981年发布的IBM 5150（又称IBM PC）交付了x86系统，其中包括Intel 8086、Intel 8042键盘控制器芯片、Intel 8259 PIC（可编程中断控制器）和Intel 8253 PIT（可编程间隔计时器）

与其他一些外围设备一样，i8253连接到i8259。在一秒钟内（18赫兹？）有几次，它在IRQ 0上向PIC发出了一个#INT信号，在确认之后，所有CPU都被中断，并执行了一个处理程序。 该处理程序可能包含调度代码，该代码决定下一个要执行的进程1

当然，到目前为止，我们（大多数人）都生活在21世纪，没有使用IBM PC或其衍生产品，如XT或AT。PIC已改为更复杂的Intel 82093AA APIC，以处理多处理器/内核，并进行总体改进，但PIT保持不变，我认为，可能是某种集成版本，如Intel AIP

---

协作调度器不需要常规中断，因此不需要特殊的硬件支持（硬件支持的多任务处理除外）。该进程故意产生CPU，如果不产生，您就有问题了。为什么很少有操作系统真正使用协作调度器：它造成了一个很大的安全漏洞

---

但是，请注意，8086上的操作系统（主要是DOS）没有真正的功能 调度程序。x86体系结构仅在本地支持多任务处理

---

随着80386版本（SX、DX等）之一的出现而出现的硬件。我想强调的是，IBM 5150是第一个带有定时器芯片的x86系统（当然，也是第一台PC）。

运行带有抢占式调度程序的操作系统的系统（即所有常用的系统）都是IME，都提供了硬件定时器中断，可导致驱动程序运行，并可更改运行线程集

这种计时器中断对于为系统调用、sleep（）功能和其他与时间相关的功能提供超时非常有用。当系统过载，或者在其上运行的线程是CPU密集型线程时，它还可以帮助在就绪线程之间共享可用CPU，因此就绪线程的数量超过可运行它们的内核的数量

---

在没有任何硬件定时器的情况下，很可能实现抢占式调度程序，允许在软件中断（系统调用）时从已经运行的线程中重新调度运行线程集，并在磁盘、NIC、KB的外围驱动程序I/O完成时重新调度所有其他中断，鼠标等。我从来没有见过这样做-计时器功能太有用了：）

是我的直觉正确吗？？？

部分，硬件计时器启动中断，由操作系统处理，在这个处理程序中它可以安排线程/进程执行，这个计时器对线程一无所知，操作系统知道为什么很少操作系统实际使用协作调度器的原因：它们的I/O性能非常差。“只有在某些中断机制以特定频率发生时，才能实现抢占，与进程无关。”-不正确。“你的解释有危险的误导性，”詹姆斯·贝特说？你是说我的全面解释？如果是的话，我可能已经偏离主题好几次了——但请告诉我更多。没有定时器中断的多任务处理不是抢占式多任务处理，而是协作式多任务处理。@ninjalj完全不正确，并且具有极大的误导性。计时器中断远不是唯一可能导致抢占的中断。