Linux CPU的上下?切换
首先说明一下Linux系统中的任务，这里的任务指的是：进程、线程或是信号触发的中断程序调用。
其次我们都知道 Linux 是?个多任务操作系统，它?持的任务同时运?的数量远远?于 CPU 的数量 。当然，这些任务实际上并不是同时运?的（Single CPU），?是因为系统在短时间内将 CPU 轮流分配给任务，造成了多个任务同时运?的假象，只是速度太快，在我们人类看来就误以为是同时运行。
1. CPU上下文
在每个任务运?之前，CPU 需要知道在哪?加载和启动任务。这意味着系统需要提前帮助设置 CPU 寄存器和程序计数器。
CPU 寄存器是内置于 CPU 中的?型但速度极快的内存。程序计数器?于存储 CPU 正在执?的或下?条要执?指令的位置。
它们都是 CPU 在运?任何任务之前必须依赖的依赖环境，因此也被称为 “CPU 上下?”。如下图所?：
2. CPU上下文切换
CPU上下?切换指的是先保存上?个任务的 CPU 上下?（CPU寄存器和程序计数器），然后将新任务的上下?加载到这些寄存器和程序计数器中，最后跳转到程序计数器。
这些保存的上下?存储在系统内核中，并在重新安排任务执?时再次加载。这确保了任务的原始状态不受影响，并且任务似乎在持续运?。
3. CPU 上下?切换的类型
CPU 上下?切换?少有三种不同的类型：
- 进程上下?切换
- 线程上下?切换
- 中断上下?切换
3.1 进程上下?切换
Linux 按照特权级别将进程的运?空间划分为内核空间和??空间，分别对应下图中 Ring 0 和
Ring 3 的 CPU 特权级别的 。
- 内核空间（
Ring 0）拥有最?权限，可以直接访问所有资源； - ??空间（
Ring 3）只能访问受限资源，不能直接访问内存等硬件设备。它必须
通过系统调?被陷?（trapped）内核中才能访问这些特权资源。
从另?个?度看，?个进程既可以在??空间也可以在内核空间运?。当?个进程在??空间运?
时，称为该进程的??态，当它落?内核空间时，称为该进程的内核态。
从??态到内核态的转换需要通过系统调?来完成。例如，当我们查看?个?件的内容时，我们需
要以下系统调?：
open()：打开?件read()：读取?件的内容write()：将?件的内容写?到输出?件（包括标准输出）close()：关闭?件
在上述系统调?过程中需要先保存 CPU 寄存器中原来的??态指令的位置。接下来，为了执?内核态的代码，需要将CPU 寄存器更新到内核态指令的新位置。最后是跳转到内核态运?内核任务。
系统调?结束后，CPU 寄存器需要恢复原来保存的??状态，然后切换到??空间继续运?进程。
因此，在?次系统调?的过程中，实际上有两次 CPU 上下?切换。
但需要指出的是，系统调?进程不会涉及进程切换，也不会涉及虚拟内存等系统资源切换。这与“进程上下?切换”不同。进程上下?切换是指从?个进程切换到另?个进程，?系统调?期间始终运?同?个进程。
系统调?过程通常被称为特权模式切换，?不是上下?切换。但实际上，在系统调?过程中，CPU的上下?切换也是不可避免的。
3.1.1 进程上下?切换 与 系统调?
进程是由内核管理的，进程切换只能发?在内核态。因此，进程上下?不仅包括虚拟内存、栈和全局变量等??空间资源，还包括内核栈和寄存器等内核空间的状态。
所以进程上下?切换?系统调?要多出?步：
- 在保存当前进程的内核状态和 CPU 寄存器之前，需要保存进程的虚拟内存、栈等；并加载下?个进程的内核状态。
进程被调度/切换到在 CPU 上运?的场景大致如下：
- 当?个进程的 CPU 时间??完时，它会被系统挂起，并切换到其他等待 CPU 运?的进程。
- 当系统资源不?（如内存不?）时，直到资源充?之前，进程?法运?。此时进程也会被挂起，系统会调度其他进程运?。
- 当一个进程通过 sleep 函数自动挂起自己时，自然会被重新调度。
- 当优先级较高的进程运行时，为了保证高优先级进程的运行，当前进程会被高优先级进程挂起运行。
- 当发生硬件中断时，CPU 上的进程会被中断挂起，转而执行内核中的中断服务程序。
ps: 了解这些场景是非常有必要的，因为一旦上下文切换出现性能问题，它们就是幕后杀手。
3.2 线程上下文切换
线程和进程最大的区别在于，线程是任务调度的基本单位，而进程是资源获取的基本单位。
说白了，内核中所谓的任务调度，实际的调度对象是线程；而进程只为线程提供虚拟内存和全局变量等资源。所以，对于线程和进程，我们可以这样理解：
- 当一个进程只有一个线程时，可以认为一个进程等于一个线程
- 当一个进程有多个线程时，这些线程共享相同的资源，例如虚拟内存和全局变量。
- 此外，线程也有自己的私有数据，比如栈和寄存器，在上下文切换时也需要保存。
线程的上下文切换其实可以分为两种情况：
- 首先，前后两个线程属于不同的进程。此时，由于资源不共享，切换过程与进程上下文切换相同。
- 其次，前后两个线程属于同一个进程。此时，由于虚拟内存是共享的，所以切换时虚拟内存的资源保持不变，只需要切换线程的私有数据、寄存器等未共享的数据。
显然，同一个进程内的线程切换比切换多个进程消耗的资源要少。这也是多线程替代多进程的优势。
3.3 中断上下文切换
除了前面两种上下文切换之外，还有另外一种场景也输出 CPU 上下文切换的，那就是中断。
为了快速响应事件，硬件中断会中断正常的调度和执行过程，进而调用中断处理程序。
在中断其他进程时，需要保存进程的当前状态，以便中断后进程仍能从原始状态恢复。
与进程上下文不同，中断上下文切换不涉及进程的用户态。因此，即使中断进程中断了处于用户态的进程，也不需要保存和恢复进程的虚拟内存、全局变量等用户态资源。
另外，和进程上下文切换一样，中断上下文切换也会消耗 CPU。过多的切换次数会消耗大量的 CPU 资源，甚至严重降低系统的整体性能。因此，当您发现中断过多时，需要注意排查它是否会对您的系统造成严重的性能问题。
4. 问题排查
4.1 常用工具
vmstat ——是?个常?的系统性能分析?具，主要?来分析系统的内存使?情况，也常?来分析
CPU上下?切换和中断的次数
pidstat ——vmstat只给出了系统总体的上下?切换情况，要想查看每个进程的详细情况，就需要
使?pidstat，加上-w，可以查看每个进程上下?切换的情况
/proc/interrupts——/proc实际上是linux的虚拟?件系统?于内核空间和??空间的通信 ，/proc/interrupts是这种通信机制的?部分，提供了?个只读的中断使?情况。
perf stat 可以统计很多和CPU相关核?数据，?如cache miss，上下?切换，CPI等。
4.2 工具使用
4.2.1 vmstat
每隔1秒输出1组数据（需要Ctrl+C才结束）
uos@uos-PC:~$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 4403616 7120 1743936 0 0 24 10 284 556 0 0 99 0 0
0 0 0 4402976 7120 1744032 0 0 0 0 961 1943 1 1 99 0 0
0 0 0 4403008 7120 1744032 0 0 0 0 2032 4034 0 0 100 0 0
0 0 0 4402528 7120 1744032 0 0 0 108 1546 3060 1 1 99 0 0
0 0 0 4402528 7120 1744032 0 0 0 0 1096 2078 0 0 100 0 0
0 0 0 4402288 7120 1744032 0 0 0 2284 1243 2521 1 1 99 0 0
0 0 0 4402256 7120 1744032 0 0 0 0 2135 4631 0 0 100 0 0
1 0 0 4427984 7120 1743920 0 0 0 0 1201 2590 1 1 99 0 0
cs（context switch）是每秒上下文切换的次数
in (interrupt)每秒中断的次数
r (Running or Runnnable)是就绪队列的长度，也就是正在运行和等待CPU的进程数。
b (Blocked) 则是处于不可中断睡眠状态的进程数
分析：
查看cs大小（实验时cs骤升到百万）
同时注意r列（实验时为8），机器cpu为1，远远超过1，必然会有大量的CPU竞争
us和sy列，计算cpu使用率总和（实验加起来快100%，其中sy高达84%，说明cpu主要被内核占用）
in列，查看大小（实验中骤升到一万，说明中断处理也是潜在的问题）
综合可知，系统的就需队列过长，也就是正在运行和等待CPU的进程数过多，导致了大量的上下文切换，而上下文切换导致了cpu占用率高
4.2.2 pidstat
pidstat是sysstat软件套件的一部分，sysstat包含很多监控linux系统状态的工具，它能够从大多数linux发行版的软件源中获得。
使用之前需要先安装
sudo aptitude install sysstat -y
每隔1秒输出1组数据（需要 Ctrl+C 才结束）
-w参数表示输出进程切换指标，而-u参数则表示输出CPU使用指标
uos@uos-PC:~$ pidstat -w -u 1
20时45分51秒 UID PID %usr %system %guest %wait %CPU CPU Command
20时45分52秒 0 581 0.99 0.00 0.00 0.00 0.99 3 deepin_ima_daem
20时45分52秒 1000 1750 0.99 1.98 0.00 0.00 2.97 2 deepin-system-m
20时45分52秒 1000 25475 0.00 0.99 0.00 0.00 0.99 2 pidstat
20时45分51秒 UID PID cswch/s nvcswch/s Command
20时45分52秒 0 10 46.53 0.00 rcu_sched
20时45分52秒 0 22 2.97 0.00 ksoftirqd/2
20时45分52秒 0 247 17.82 0.00 xfsaild/nvme0n1
20时45分52秒 0 312 0.99 0.00 systemd-journal
20时45分52秒 0 547 21.78 0.00 haveged
20时45分52秒 0 578 0.99 0.00 uos-resource-ma
20时45分52秒 106 590 5.94 0.00 dbus-daemon
20时45分52秒 0 591 1.98 0.00 wpa_supplicant
20时45分52秒 0 592 0.99 0.00 NetworkManager
20时45分52秒 0 722 0.99 0.00 systemd-hostnam
20时45分52秒 0 1186 13.86 0.00 Xorg
20时45分52秒 1000 1292 5.94 0.00 dbus-daemon
20时45分52秒 1000 1393 0.99 0.00 dde-desktop
20时45分52秒 1000 1456 2.97 0.00 dde-dock
20时45分52秒 0 1582 3.96 0.00 lastore-daemon
20时45分52秒 1000 1719 0.99 0.00 deepin-system-m
20时45分52秒 1000 1750 1.98 0.00 deepin-system-m
20时45分52秒 0 1861 1.98 0.00 deepin-MonitorN
20时45分52秒 0 2260 0.99 0.00 dde-file-manage
20时45分52秒 1000 2262 19.80 0.00 deepin-deepinid
20时45分52秒 0 2487 14.85 0.00 ipwatchd
20时45分52秒 0 2492 0.99 0.00 deepin-devicema
20时45分52秒 1000 3460 1.98 0.00 uos-activator
20时45分52秒 0 20938 1.98 0.00 kworker/0:2-events
20时45分52秒 0 23914 0.99 0.00 kworker/1:2-mm_percpu_wq
20时45分52秒 0 25192 0.99 0.00 kworker/3:1-events_power_efficient
20时45分52秒 0 25276 0.99 0.00 kworker/2:2-mm_percpu_wq
20时45分52秒 1000 25475 0.99 0.00 pidstat
cswch 表示每秒自愿上下文切换的次数，是指进程无法获取所需资源，导致的上下文切换，比如说，I/O，内存等系统资源不足时，就会发生自愿上下文切换。
nvcswch 表示每秒非自愿上下文切换的次数，则是指进程由于时间片已到等原因，被系统强制调度，进而发生的上下文切换。
分析：
pidstat查看果然是sysbench导致了cpu达到100%，但上下文切换来自其他进程，包括非自愿上下文切换最高的pidstat，以及自愿上下文切换最高的kworker和sshd
但pidtstat输出的上下文切换次数加起来才几百和vmstat的百万明显小很多，现在vmstat输出的是线程，而pidstat加上-t后才输出线程指标
每隔1秒输出一组数据（需要 Ctrl+C 才结束）
-wt 参数表示输出线程的上下文切换指标
uos@uos-PC:~$ pidstat -wt 1
20时48分22秒 UID TGID TID cswch/s nvcswch/s Command
20时48分23秒 0 10 - 23.08 0.00 rcu_sched
20时48分23秒 0 - 10 23.08 0.00 |__rcu_sched
20时48分23秒 0 12 - 0.96 0.00 migration/0
20时48分23秒 0 - 12 0.96 0.00 |__migration/0
20时48分23秒 0 16 - 0.96 0.00 migration/1
20时48分23秒 0 - 16 0.96 0.00 |__migration/1
20时48分23秒 0 21 - 0.96 0.00 migration/2
20时48分23秒 0 - 21 0.96 0.00 |__migration/2
20时48分23秒 0 22 - 5.77 0.00 ksoftirqd/2
20时48分23秒 0 - 22 5.77 0.00 |__ksoftirqd/2
20时48分23秒 0 26 - 0.96 0.00 migration/3
20时48分23秒 0 - 26 0.96 0.00 |__migration/3
20时48分23秒 0 247 - 18.27 0.00 xfsaild/nvme0n1
20时48分23秒 0 - 247 18.27 0.00 |__xfsaild/nvme0n1
20时48分23秒 0 547 - 13.46 0.00 haveged
20时48分23秒 0 - 547 13.46 0.00 |__haveged
20时48分23秒 0 578 - 1.92 0.00 uos-resource-ma
20时48分23秒 0 - 578 1.92 0.00 |__uos-resource-ma
20时48分23秒 0 - 608 3.85 0.00 |__uos-resource-ma
20时48分23秒 0 - 660 2.88 0.00 |__uos-resource-ma
20时48分23秒 0 - 661 1.92 0.00 |__uos-resource-ma
20时48分23秒 0 - 631 191.35 0.00 |__deepin_ima_daem
20时48分23秒 0 - 633 4.81 2.88 |__deepin_ima_daem
20时48分23秒 0 - 678 5.77 0.00 |__deepin_ima_daem
20时48分23秒 0 - 680 4.81 0.00 |__deepin_ima_daem
20时48分23秒 0 - 6589 1.92 0.00 |__deepin_ima_daem
4.2.3 查看中断
可排查是哪些中断引起的（变化速度最快的）
-d 参数表示高亮显示变化的区域
watch -d cat /proc/interrputs
观察一段时间后，可以发现变化最快的是重新调度中断（RES, REScheduling interrupt）。这种中断类型表明处于空闲状态的 CPU 被唤醒以调度新的任务运行。所以这里的中断增加是因为太多的任务调度问题，这和前面上下文切换次数的分析结果是一致的.
4.2.4 perf
现在回到最初的问题，每秒多少次上下文切换是正常的？
这个值实际上取决于系统本身的 CPU 性能。如果系统的上下文切换次数比较稳定的话，几百到一万应该是正常的。但是，当上下文切换次数超过 10000，或者切换次数快速增加时，很可能是出现了性能问题。
perf stat 可以排查系统上下文切换速率变化
uos@uos-PC:~$ sudo perf stat -a
Performance counter stats for 'system wide':
448,484.38 msec cpu-clock # 8.000 CPUs utilized
109,154 context-switches # 243.384 M/sec
2,000 cpu-migrations # 4.459 M/sec
87,450 page-faults # 194.990 M/sec
13,541,792,770 cycles # 30194.595 GHz
9,826,295,054 instructions # 0.73 insn per cycle
<not supported> branches
73,395,182 branch-misses
56.061103753 seconds time elapsed
cpu-clock：任务真正占用的处理器时间，单位为ms。CPUs utilized = task-clock / time elapsed，CPU的占用率。
context-switches：程序在运行过程中上下文的切换次数。
CPU-migrations：程序在运行过程中发生的处理器迁移次数。Linux为了维持多个处理器的负载均衡，在特定条件下会将某个任务从一个CPU迁移到另一个CPU。
CPU迁移和上下文切换：发生上下文切换不一定会发生CPU迁移，而发生CPU迁移时肯定会发生上下文切换。发生上下文切换有可能只是把上下文从当前CPU中换出，下一次调度器还是将进程安排在这个CPU上执行。
page-faults：缺页异常的次数。当应用程序请求的页面尚未建立、请求的页面不在内存中，或者请求的页面虽然在内存中，但物理地址和虚拟地址的映射关系尚未建立时，都会触发一次缺页异常。另外TLB不命中，页面访问权限不匹配等情况也会触发缺页异常。
cycles：消耗的处理器周期数。如果把被ls使用的cpu cycles看成是一个处理器的，那么它的主频为2.486GHz。可以用cycles / task-clock算出。
stalled-cycles-frontend：指令读取或解码的质量步骤，未能按理想状态发挥并行左右，发生停滞的时钟周期。
stalled-cycles-backend：指令执行步骤，发生停滞的时钟周期。
instructions：执行了多少条指令。IPC为平均每个cpu cycle执行了多少条指令。
branches：遇到的分支指令数。branch-misses是预测错误的分支指令数。
可以观察context-switcehes 数据的变化，有没有突增，可以发现一些异常想象。
场景
- 根据调度策略，将CPU时间划片为对应的时间片，当时间片耗尽，当前进程必须挂起。
- 资源不足的，在获取到足够资源之前进程挂起。
- 进程sleep挂起进程。
- 高优先级进程导致当前进度挂起
- 硬件中断，导致当前进程挂起
5. 小结：
-
CPU 上下文切换是保证 Linux 系统正常运行的核心功能之一，一般不需要我们特别关注。
-
但是过多的上下文切换会消耗 CPU 的时间来保存和恢复寄存器、内核栈、虚拟内存等数据，从而缩短进程的实际运行时间，导致系统整体性能显着下降。
-
自愿上下文切换变多了，说明进程都在等待资源，有可能发生了 I/O 等其他问题
-
非自愿上下文切换变多了，说明进程都在被强制调度，也就是都在争抢 CPU，说明 CPU 的确成了瓶颈
-
中断次数变多了，说明 CPU 被中断处理程序占用，还需要通过查看
/proc/interrupts文件来分析具体的中断类型。