进程切换和线程切换

 

为了控制进程的执行，内核必须有能力挂起正在CPU上运行的进程，并恢复以前挂起的某个进程的执行。这种行为被称为进程切换（process switch）、任务切换（task switch）或上下文切换（content switch）。

原文 ：https://www.cnblogs.com/kkshaq/p/4547725.html

进程切换分两步：

1.切换页目录以使用新的地址空间

2.切换内核栈和硬件上下文

对于linux来说，线程和进程的最大区别就在于地址空间，对于线程切换，第1步是不需要做的，第2是进程和线程切换都要做的。

切换的性能消耗：

1、线程上下文切换和进程上下问切换一个最主要的区别是线程的切换虚拟内存空间依然是相同的，但是进程切换是不同的。这两种上下文切换的处理都是通过操作系统内核来完成的。内核的这种切换过程伴随的最显著的性能损耗是将寄存器中的内容切换出。

2、另外一个隐藏的损耗是上下文的切换会扰乱处理器的缓存机制。简单的说，一旦去切换上下文，处理器中所有已经缓存的内存地址一瞬间都作废了。还有一个显著的区别是当你改变虚拟内存空间的时候，处理的页表缓冲（processor’s Translation Lookaside Buffer (TLB)）会被全部刷新，这将导致内存的访问在一段时间内相当的低效。但是在线程的切换中，不会出现这个问题。

 

系统调用：处于进程上下文

系统调用是在进程上下文中,并没有tasklet之类的延迟运行,系统调用本身可以休眠,这些可以参见内核代码
 

虽然系统调用实与其他中断实现有点类似,通过IDT表查找入口处理函数,但是系统调用与其他中断最大的不同是,系统调用是代表当前进程执行的,所以current宏/task_struct是有意义的,这个休眠可以被唤醒

 

系统调用，异常，中断（其中中断是异步时钟，异常时同步时钟），也可以把系统调用成为异常

中断上下文：在中断中执行时依赖的环境，就是中断上下文（不包括系统调用，是硬件中断）

进程上下文：当一个进程在执行时,CPU的所有寄存器中的值、进程的状态以及堆栈中的内容被称为该进程的上下文

1、首先，这两个上下文都处于内核空间。

2、其次，两者的区别在于，进程上下文与当前执行进程密切相关，而中断上下文在逻辑上与进程没有关系。

进程上下文主要是异常处理程序和内核线程。内核之所以进入进程上下文是因为进程自身的一些工作需要在内核中做。例如，系统调用是为当前进程服务的，异常通常是处理进程导致的错误状态等。所以在进程上下文中引用current是有意义的。

内核进入中断上下文是因为中断信号而导致的中断处理或软中断。而中断信号的发生是随机的，中断处理程序及软中断并不能事先预测发生中断时当前运行的是哪个进程，所以在中断上下文中引用current是可以的，但没有意义。事实上，对于A进程希望等待的中断信号，可能在B进程执行期间发生。例如，A进程启动写磁盘操作，A进程睡眠后现在时B进程在运行，当磁盘写完后磁盘中断信号打断的是B进程，在中断处理时会唤醒A进程。
上下文这个词会让人想到进程的CPU寄存器状态，但好像进入进程上下文（异常处理系统调用）和进入中断上下文（中断处理），内核所做的工作没有太大区别。所以，这两个上下文的主要区别，我认为在于是否与进程相关。

运行于进程上下文的内核代码是可抢占的，但中断上下文则会一直运行至结束，不会被抢占。因此，内核会限制中断上下文的工作，不允许其执行如下操作：

(1) 进入睡眠状态或主动放弃CPU;

由于中断上下文不属于任何进程，它与current没有任何关系（尽管此时current指向被中断的进程），所以中断上下文一旦睡眠或者放弃CPU，将无法被唤醒。所以也叫原子上下文（atomic context）。

　　(2) 占用互斥体;

为了保护中断句柄临界区资源，不能使用mutexes。如果获得不到信号量，代码就会睡眠，会产生和上面相同的情况，如果必须使用锁，则使用spinlock。

　　(3) 执行耗时的任务;

中断处理应该尽可能快，因为内核要响应大量服务和请求，中断上下文占用CPU时间太长会严重影响系统功能。在中断处理例程中执行耗时任务时，应该交由中断处理例程底半部来处理。

　　(4) 访问用户空间虚拟内存。

因为中断上下文是和特定进程无关的，它是内核代表硬件运行在内核空间，所以在中断上下文无法访问用户空间的虚拟地址

 　　(5) 中断处理例程不应该设置成reentrant（可被并行或递归调用的例程）。

因为中断发生时，preempt和irq都被disable，直到中断返回。所以中断上下文和进程上下文不一样，中断处理例程的不同实例，是不允许在SMP上并发运行的。

　　(6)中断处理例程可以被更高级别的IRQ中断。（不能嵌套中断）使用软中断，上部分关中断，也就是禁止嵌套，下半部分使用软中断

如果想禁止这种中断，可以将中断处理例程定义成快速处理例程，相当于告诉CPU，该例程运行时，禁止本地CPU上所有中断请求。这直接导致的结果是，由于其他中断被延迟响应，系统性能下降。

 软中断是一种延时机制，代码执行的优先级比进程要高，比硬中断要低。相比于硬件中断，软中段是在开中断的环境中执行的（长时间关中断对系统的开销太大）， 代码是执行在中断/线程上下文的，是不能睡眠的，虽然每个cpu都有一个对应的ksoftirqd/n线程来执行软中断，但是do_softirq这个函数也还会在中断退出时调用到，因此不能睡眠(中断上下文不能睡眠的原因是由于调度系统是以进程为基本单位的，调度时会把当前进程的上下文保存在task_struct这个数据结构中，当进程被调度重新执行时会找到执行的断点，但是中断上下文是没有特定task_struct结构体的，当然现在有所谓的线程话中断，可以满足在中断处理函数执行阻塞操作，但是实时性可能会有问题。还有就是中断代表当前进程执行的概念，个人感觉有点扯淡，毕竟整个内核空间是由所有进程共享的，不存在代表的概念)

上面我们介绍的可延迟函数运行在中断上下文中（软中断的一个检查点就是do_IRQ退出的时候），于是导致了一些问题：软中断不能睡眠、不能阻塞。由于中断上下文出于内核态，没有进程切换，所以如果软中断一旦睡眠或者阻塞，将无法退出这种状态，导致内核会整个僵死。但可阻塞函数不能用在中断上下文中实现，必须要运行在进程上下文中，例如访问磁盘数据块的函数。因此，可阻塞函数不能用软中断来实现。但是它们往往又具有可延迟的特性。