内核中内置的调度程序是程序还是进程？
我查阅了内核中内置的CPU调度程序源代码。 https://github.com/torvalds/linux/tree/master/kernel/ sched
但我有一个问题。 网上对于cpu调度器的看法褒贬不一。
- 我看到一个观点，CPU调度器是一个进程。
问题：如果是这样，当在 Linux 上 ps-ef 时，调度程序进程应该是可见的。很难找到调度程序进程的 PID 和名称。 CPU 调度程序进程的 PID 也不在互联网上。然而，PID 0 SWAPPER进程称为SCHED，但在Linux中，PID 0充当空闲进程。
- 我看到一个观点，CPU调度器不是一个进程。 CPU调度器是内置于内核中的被动源代码，用户进程频繁进入内核并轮转源代码。
问题：用户进程如何自行执行内核的调度器源代码？ 如果您创建了一个用户程序而不使用内核的调度程序添加系统调用怎么办？ 如果没有这样的代码，用户进程如何在内核中自行轮换调度程序？
I looked up the CPU scheduler source code built into the kernel.
https://github.com/torvalds/linux/tree/master/kernel/sched
But I have a question.
There are mixed opinions on the cpu scheduler on the Internet.
- I saw an opinion that CPU scheduler is a process.
Question: If so, when ps-ef on Linux, the scheduler process should be visible. It was difficult to find the PID and name of the scheduler process.
The PID for the CPU scheduler process is not on the internet either. However, the PID 0 SWAPPER process is called SCHED, but in Linux, PID 0 functions as an idle process.
- I saw an opinion that CPU scheduler is not a process.
CPU scheduler is a passive source code built into the kernel, and user processes frequently enter the kernel and rotate the source code.
Question: How does the user process execute the kernel's scheduler source code on its own?
What if you created a user program without adding a system call using the scheduler of the kernel?
How does the user process self-rotate the scheduler in the kernel without such code?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您有 2 个类似的问题（认为内核内置的调度程序是程序的观点和认为它是进程的观点和我想知道如何在Linux操作系统中实现cpu调度过程）所以我将在这里回答这两个问题。
答案是根本行不通。用户模式进程不使用系统调用来调用调度程序。调度程序不是系统调用。有些定时器被编程为在一段时间过去后引发中断。使用寄存器访问定时器，这些寄存器是 RAM 中的内存，通常称为内存映射 IO (MMIO)。您写入 ACPI 表指定的 RAM 中的某个位置 (https://wiki.osdev.org/ACPI) 并且它将允许控制 CPU 中的芯片或外部 PCI 设备（现在 PCI 就是一切）。
当定时器达到0时，就会触发中断。中断由硬件（CPU）引发。因此，CPU 包含特殊机制，让操作系统确定中断时跳转的位置 (https://wiki .osdev.org/Interrupt_Descriptor_Table）。 CPU 使用中断来通知操作系统发生了事件。如果没有中断，操作系统将必须为特殊的内核进程保留至少一个处理器核心，该进程将不断轮询外设和其他事物的寄存器。这是不可能实施的。另外，如果用户模式进程自己进行调度程序系统调用，内核将成为用户模式的奴隶，因为它无法判断进程是否已完成，并且进程可能会在 CPU 时间上自私。
我没有查看源代码，但我认为调度程序也经常在某些 IO 完成时被调用（也在中断时但并不总是在定时器中断时）。我非常确定调度程序一定不能被抢占。也就是说，当schedule()函数运行时，中断（和其他事情）将被禁用。
我不认为你可以将调度程序称为进程（甚至不能称为内核线程）。调度程序可以由由于下半部分处理而产生的中断所创建的内核线程来调用。在下半部处理中，中断处理程序的上“半部”快速高效地运行，而下“半部”则添加到进程队列中，并在调度程序决定应该对其进行调度时运行。这具有创建一些内核线程的效果。因此，可以从内核线程调用调度程序，但并不总是从中断的下半部分调用。必须有一种机制来调用调度程序，而调度程序不必自行调度任务。否则，内核将停止运行。
You have 2 similar questions (The opinion that the scheduler built into the kernel is the program and the opinion that it is the process and I want to know how to implement the cpu scheduling process in Linux operating system) so I'll answer for both of these here.
The answer is that it doesn't work that way at all. The scheduler is not called by user mode processes by using system calls. The scheduler isn't a system call. There are timers that are programmed to throw interrupts after some time has elapsed. Timers are accessed using registers that are memory in RAM often called memory mapped IO (MMIO). You write to some position in RAM specified by the ACPI tables (https://wiki.osdev.org/ACPI) and it will allow to control the chips in the CPU or external PCI devices (PCI is everything nowadays).
When the timer reaches 0, it will trigger an interrupt. Interrupts are thrown by hardware (the CPU). The CPU thus includes special mechanism to let the OS determine the position at which it will jump on interrupt (https://wiki.osdev.org/Interrupt_Descriptor_Table). Interrupts are used by the CPU to notify the OS that an event happened. Without interrupts, the OS would have to reserve at least one core of the processor for a special kernel process that would constantly poll the registers of peripherals and other things. It would be impossible to implement. Also, if user mode processes did the scheduler system call by themselves, the kernel would be slave to user mode because it wouldn't be able to tell if a process is finished and processes could be selfish over CPU time.
I didn't look at the source code but I think the scheduler is also often called on some IO completion (also on interrupt but not always on timer interrupt). I am quite sure that the scheduler must not be preempted. That is interrupts (and other things) will be disabled while the schedule() function runs.
I don't think you can call the scheduler a process (not even a kernel thread). The scheduler can be called by kernel threads that are created by interrupts due to bottom half processing. In bottom half processing, the top "half" of the interrupt handler runs fast and efficiently while the bottom "half" is added to the queue of processes and runs when the scheduler decides it should be scheduled. This has the effect of creating some kernel threads. The scheduler can thus be called from kernel threads but not always from bottom half of interrupts. There has to be a mechanism to call the scheduler without the scheduler having to schedule the task itself. Otherwise, the kernel will stop functioning.