Linux调度程序是否需要上下文切换? [英] Does the linux scheduler needs to be context switched?
问题描述
我对linux调度程序和其他一些类似的内核系统调用有一个一般性的疑问.
Linux调度程序是否被视为进程"，并且每次对调度程序的调用都需要上下文切换，就像它只是另一个进程一样?
假设我们有一个时钟滴答声，它会中断当前正在运行的用户模式进程，现在我们必须调用调度程序.对调度程序的调用本身会引起上下文切换吗?调度程序是否具有自己的寄存器和U区域集，并且在每次调用时都必须还原?
上述问题适用于许多其他系统调用.就上下文切换而言，内核进程的行为是否像常规进程一样，唯一的区别是它们具有更多的权限和对cpu的访问权限?
我之所以这样问，是因为上下文切换的开销很大.听起来奇怪的是，调用调度程序本身会引起上下文切换以恢复调度程序状态，然后调度程序调用另一个进程来运行，并再次调用另一个上下文切换.
这是一个很好的问题，答案是肯定的，除了硬件知道操作系统和任务的概念外调度程序.
在硬件中，您会发现限于管理程序"模式的寄存器.在不过多介绍内部CPU架构的情况下，有一个用于用户模式"和管理员模式"的基本程序执行寄存器的副本，后者只能由OS本身访问(通过操作系统中的标志访问).内核设置的控制寄存器，用于说明内核或用户模式应用程序当前是否正在运行.
因此，您所说的上下文切换"是交换/重置用户模式寄存器(指令寄存器，堆栈指针寄存器等)的过程，但是系统寄存器没有需要将其替换掉，因为它们与用户存储区分开存储.
例如，x86中的用户模式堆栈是USP-A7，而超级用户模式堆栈是SSP-A7.因此，内核本身(包含任务调度程序)将使用管理程序模式堆栈和其他管理程序模式寄存器运行自身，在运行时将管理程序模式标志设置为1，然后在用户模式硬件上执行上下文切换 以便在应用之间切换，并将超级用户模式标志设置为0.
但是在操作系统和任务计划的概念出现之前，如果您想做一个多任务系统，那么您必须使用问题中概述的基本概念:使用硬件中断来每次调用任务计划程序x个周期，然后换出任务调度程序的应用程序，然后换入新的应用程序.但是在大多数情况下，计时器中断将是您实际的任务调度程序本身，并且将对其进行大量优化，以使其更少的上下文切换而更多的是简单的中断处理程序例程.
I have a general question about the linux scheduler and some other similar kernel system calls.
Is the linux scheduler considered a "process" and every call to the scheduler requires a context switch like its just another process?
Say we have a clock tick which interrupts the current running user mode process, and we now have to call the scheduler. Does the call to the scheduler itself provokes a context switch? Does the scheduler has its own set of registers and U-area and whatnot which it has to restore at every call?
And the said question applies to many other system calls. Do kernel processes behave like regular processes in regard to context switching, the only difference is that they have more permissions and access to the cpu?
I ask this because context switch overhead is expensive. And it sounds odd that calling the scheduler itself provokes a context switch to restore the scheduler state, and after that the scheduler calls another process to run and again another context switch.
That's a very good question, and the answer to it would be "yes" except for the fact that the hardware is aware of the concept of an OS and task scheduler.
In the hardware, you'll find registers that are restricted to "supervisor" mode. Without going into too much detail about the internal CPU architecture, there's a copy of the basic program execution registers for "user mode" and "supervisor mode," the latter of which can only be accessed by the OS itself (via a flag in a control register that the kernel sets which says whether or not the kernel or a user mode application is currently running).
So the "context switch" you speak of is the process of swapping/resetting the user mode registers (instruction register, stack pointer register, etc.) etc. but the system registers don't need to be swapped out because they're stored apart from the user ones.
For instance, the user mode stack in x86 is USP - A7, whereas the supervisor mode stack is SSP - A7. So the kernel itself (which contains the task scheduler) would use the supervisor mode stack and other supervisor mode registers to run itself, setting the supervisor mode flag to 1 when it's running, then perform a context switch on the user mode hardware to swap between apps and setting the supervisor mode flag to 0.
But prior to the idea of OSes and task scheduling, if you wanted to do a multitasking system then you'd have had to use the basic concept that you outlined in your question: use a hardware interrupt to call the task scheduler every x cycles, then swap out the app for the task scheduler, then swap in the new app. But in most cases the timer interrupt would be your actual task scheduler itself and it would have been heavily optimized to make it less of a context switch and more of a simple interrupt handler routine.
这篇关于Linux调度程序是否需要上下文切换?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
