当我们谈上下文切换时我们在谈些什么

        相信不少小伙伴面试时，都被问到过这样一个问题：进程和线程的区别是什么？大学老师会告诉我们：进程是资源分配的基本单位，线程是调度的基本单位。说到调度，就不得不提到CPU的上下文切换了。

何为CPU上下文切换

：“CPU上下文切换，这是个啥呢？”

：“唔！我来告诉你吧。。在多猫系统中，上下文切换时很常见的事情。。。饭盆的个数是有限的，一只猫一天的猫粮也是有数的。有的猫吃了一半的猫粮，要把它剩下的猫粮暂存起来，把饭盆里的猫粮切换为另一只猫的！”

        “类似地，这个玩意放在计算机里面也是一样的！”

        在多任务操作系统中，CPU需要在不同的进程或线程之间切换，以实现并发执行。每个进程或线程都有自己的上下文：CPU寄存器状态。

        CPU 寄存器，是 CPU 内置的容量小、但速度极快的存储。比如：

        程序计数器（Program Counter，PC）：也称为指令计数器，通常是放在CPU内部的一个特殊寄存器中的。程序计数器的主要作用是存储下一条要执行的指令的地址。当CPU执行指令时，程序计数器会更新为下一条指令的地址，确保CPU能够按顺序执行程序中的指令。

        页表的起始地址：每个进程都有自己的虚拟内存，在内核中，需要通过页表来映射虚拟内存到物理内存，页表的起始地址一般存放在页表基址寄存器。

        这些寄存器状态，它们所维护的环境，都是 CPU 在运行任何任务前，必须的依赖环境，因此也被叫做 CPU 上下文。当操作系统决定从当前执行的任务切换到另一个任务时，它需要保存当前任务的上下文，并加载新任务的上下文，这个过程就是上下文切换。

上下文切换的种类

：“寄存器不是极快吗，怎么老是听说上下文切换开销很大？”

        前面说了，CPU保存旧任务的上下文，切换新任务的上下文，然后开始执行新任务。那切换从任务角度来讲，有这么几种：

进程上下文切换

        众所周知，进程由内核来管理和调度，每个进程有自己的时间片，时间片耗尽，进程还没有结束，就会被内核调度出去重新排队等待，转而切换一个新的已就绪进程开始执行。这个过程就需要进行进程上下文切换。

        都知道，虚拟内存需要通过页表转换为物理内存，由于多级页表多次访问内存效率太低，增加了快表(TLB)，大大提升了地址转换的效率。由于进程切换，新老进程的页表肯定是不一样的，这就会导致快表失效，继而新的进程要将虚拟地址转换到物理地址无法使用快表缓存。类似的，CPU还有多级缓存，也存在相应的缓存失效场景，没有缓存，当然慢啊。所以，进程上下文切换开销是比较大的。

线程上下文切换

        大学老师提醒过我们了：线程是调度的基本单位，而进程则是资源分配的基本单位。说白了，所谓内核中的任务调度，实际上的调度对象是线程；而进程只是给线程提供了进程栈等资源。同一个进程的不同线程，共享了进程ID、打开的文件描述符、根目录等等资源。

        那么理所应当的，同一个进程的不同线程间的上下文切换，开销较小，因为部分资源是共享的。当然开销还是有一定开销的，比如线程有自己的私有的线程栈、线程ID、程序计数器等资源。

        至于不同进程的线程的切换，其实就是前面说的：进程上下文切换。

中断上下文切换

中断是硬件设备用来通知 CPU 需要处理某些事件的机制。当硬件设备如网络卡、硬盘、鼠标或键盘等需要 CPU 注意时，它们会发送一个中断信号。CPU 响应这个信号，并执行相应的中断服务例程（ISR）来处理事件。

        如果你打开了一个文本编辑器，输入了一个字符‘a’，键盘控制器会向 CPU 发送一个中断信号。CPU 接收到中断信号后，会停止执行当前正在执行的任务，并跳转到键盘中断处理程序。键盘中断处理程序会读取键盘控制器中的数据，并根据这些数据来确定用户按下了哪个键。然后，键盘中断处理程序会将这个信息传递给用户程序，用户程序就会显示你插入了一个‘a’。

        在这个过程中，中断处理打断了进程的正常调度和执行顺序，转而调用中断处理程序，响应来自键盘的设备事件。而在打断其他进程时，就需要将进程当前的状态保存下来，这样在中断结束后，进程仍然可以从原来的状态恢复运行。

        跟进程上下文不同，中断上下文切换并不涉及到进程用户态资源的访问。所以，即便中断过程打断了一个正处在用户态的进程，也不需要保存和恢复这个进程的进程栈等用户态资源。中断上下文，其实只包括内核态中断服务程序执行所必需的状态，包括 CPU 寄存器、内核堆栈、硬件中断参数等等。

上下文切换过多的问题

        上下文切换虽然是操作系统设计中的必要机制，但是过多的上下文切换会导致CPU花费大量时间在任务切换上，而不是任务执行上，从而降低系统的整体性能。这种情况通常发生在以下几种情况：

• 系统中运行了过多的进程或线程。
• 高频率的IO操作导致频繁的中断。
• 锁竞争激烈，导致线程频繁地进入和退出临界区。

排查上下文切换过多的问题

当我们怀疑系统性能下降可能是由于上下文切换过多时，可以通过以下方法进行排查：

vmstat命令

        vmstat用来查看关于系统的虚拟内存、进程、CPU活动以及IO统计的信息。vmstat提供了关于系统性能的即时报告，帮助管理员理解系统的内存使用情况、进程状态、系统等待队列以及磁盘IO和CPU使用情况。vmstat的输出通常包含以下几个部分：

procs（进程）：
    r：等待运行的进程数。
    b：处于不可中断睡眠状态的进程数。
memory（内存）：
    swpd：虚拟内存使用量。
    free：空闲内存量。
    buff：用作缓冲的内存量。
    cache：用作缓存的内存量。
swap（交换空间）：
    si：每秒从交换空间读入内存的量。
    so：每秒写入交换空间的内存量。
io（输入/输出）：
    bi：每秒读取的块数。
    bo：每秒写入的块数。
system（系统）：
    in：每秒中断次数，包括时钟中断。
    cs：每秒上下文切换次数。
cpu（处理器）：
    us：用户空间占用CPU的百分比。
    sy：内核空间占用CPU的百分比。
    id：空闲CPU百分比。
    wa：等待IO的CPU时间百分比。
    st：被偷取的时间百分比（在虚拟化环境中，其他虚拟机占用的CPU时间）。

每2秒输出一次报告，共输出3次：

（ps：通过命令模拟了多线程并发场景：sysbench --threads=10 --max-time=300 threads run）
root@gl:/home/gl# vmstat 2 3
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 6  0      0 1250924  48464 600112    0    0    17    10  195  972  0  1 99  0  0
 5  0      0 1250924  48464 600112    0    0     0     0 16138 743482 23 72  5  0  0
 5  0      0 1250924  48464 600112    0    0     0     0 15653 737597 22 71  7  0  0

        vmstat第一行的输出表示的是自系统启动以来的平均负载，后面的行才表示当前间隔时间内的状态。从上面的数据可以看出来，自启动启动以来，(cs)平均上下文切换、(in)每秒中断次数都比较低。但是当前时间下，cs和in突发性的增大了好几个数量级！

        前面说了，引发上下文切换过多可能的原因大致有三种：线程/进程太多、io频繁、锁频繁。接下来进一步再通过pidstat分析一下是哪种原因。

pidstat

pidstat是一个监控个别任务的性能的工具，可以用来查看特定进程的上下文切换情况。运行看下输出：

root@gl:/home/gl# pidstat -wt 1
Linux 4.15.0-213-generic (gl)   01/17/2024      _x86_64_        (2 CPU)

06:49:41 AM   UID      TGID       TID   cswch/s nvcswch/s  Command
06:49:42 AM     0         7         -      2.83      0.00  ksoftirqd/0
06:49:42 AM     0         -         7      2.83      0.00  |__ksoftirqd/0
06:49:42 AM     0         8         -     28.30      0.00  rcu_sched
06:49:42 AM     0         -         8     28.30      0.00  |__rcu_sched
06:49:42 AM     0       123         -      0.94      0.00  kworker/1:2
06:49:42 AM     0         -       123      0.94      0.00  |__kworker/1:2
...
06:49:42 AM     0     10180     10181   7343.40  69718.87  (sysbench)__sysbench
06:49:42 AM     0         -     10182   8820.75  60550.00  |__sysbench
06:49:42 AM     0         -     10183   7120.75  66724.53  |__sysbench
06:49:42 AM     0         -     10184   5205.66  65349.06  |__sysbench
06:49:42 AM     0         -     10185   8678.30  65187.74  |__sysbench
06:49:42 AM     0         -     10186   8339.62  66105.66  |__sysbench
06:49:42 AM     0         -     10187   6755.66  55736.79  |__sysbench
06:49:42 AM     0         -     10188   6559.43  62579.25  |__sysbench
06:49:42 AM     0         -     10189   7974.53  61872.64  |__sysbench
06:49:42 AM     0         -     10190   5702.83  64549.06  |__sysbench
06:49:42 AM     0     10192         -      0.94      0.94  pidstat
06:49:42 AM     0         -     10192      0.94      0.94  |__pidstat

其中有两列可以重点关注一下：

• cswch/s，表示每秒自愿上下文切换（voluntary context switches）的次数。
• nvcswch/s，表示每秒非自愿上下文切换（non voluntary context switches）的次数。

        所谓自愿上下文切换，是指进程所需资源尚未就绪，导致的上下文切换。比如说， 内存、IO、锁等系统资源不足或者时，就会发生自愿上下文切换。而非自愿上下文切换，则是指进程由于时间片已到等原因，被系统强制调度导致的上下文切换。比如说，大量进程都在就绪队列等待，就容易发生非自愿上下文切换。

        可以看到sysbench这个程序有多个子线程，存在大量的上下文切换，尤其以非自愿上下文切换为多。此时可以合理怀疑是由于sysbench线程数太多导致cpu上下文频繁切换引起的系统卡顿。 

        再回到vmstat的输出，不仅(cs)切换次数高，(in)中断数也高，所以此时也不能断定就是线程数太多导致的，因为也可能是某种中断次数太多导致中断上下文切换频繁！

/proc/interrupts

        /proc/interrupts 是 Linux 系统中的一个特殊文件，它提供了关于 CPU 中断的实时信息。这个文件包含了系统中每个中断请求（IRQ）的统计数据，包括每个中断的编号、类型、设备名称以及每个 CPU 上的中断计数。

：

root@gl:/home/gl# cat /proc/interrupts 
           CPU0       CPU1       
...
NMI:          0          0   Non-maskable interrupts
LOC:     293139     729565   Local timer interrupts
SPU:          0          0   Spurious interrupts
PMI:          0          0   Performance monitoring interrupts
IWI:          0          0   IRQ work interrupts
RTR:          0          0   APIC ICR read retries
RES:    2889219    2818044   Rescheduling interrupts
CAL:       7324       1630   Function call interrupts
TLB:         17         38   TLB shootdowns
TRM:          0          0   Thermal event interrupts
THR:          0          0   Threshold APIC interrupts
DFR:          0          0   Deferred Error APIC interrupts
...

        多输出几次就可以发现，其中增长比较明显的是Rescheduling interrupts。从字面意思也可以看出来，这个中断表示重调度中断，也就是cpu调度任务触发的中断。

：“这下可以石锤了，还说不是你？”

sysbench：