我們都知道 Linux 是一個多任務(wù)操作系統(tǒng)，它支持的任務(wù)同時運行的數(shù)量遠遠大于 CPU 的數(shù)量。當然，這些任務(wù)實際上并不是同時運行的（Single CPU），而是因為系統(tǒng)在短時間內(nèi)將 CPU 輪流分配給任務(wù)，造成了多個任務(wù)同時運行的假象。

CPU 上下文（CPU Context）

在每個任務(wù)運行之前，CPU 需要知道在哪里加載和啟動任務(wù)。這意味著系統(tǒng)需要提前幫助設(shè)置 CPU 寄存器和程序計數(shù)器。

CPU 寄存器是內(nèi)置于 CPU 中的小型但速度極快的內(nèi)存。程序計數(shù)器用于存儲 CPU 正在執(zhí)行的或下一條要執(zhí)行指令的位置。

它們都是 CPU 在運行任何任務(wù)之前必須依賴的依賴環(huán)境，因此也被稱為 “CPU 上下文”。如下圖所示：

知道了 CPU 上下文是什么，我想你理解CPU 上下文切換就很容易了。“CPU上下文切換”指的是先保存上一個任務(wù)的 CPU 上下文（CPU寄存器和程序計數(shù)器），然后將新任務(wù)的上下文加載到這些寄存器和程序計數(shù)器中，最后跳轉(zhuǎn)到程序計數(shù)器。

這些保存的上下文存儲在系統(tǒng)內(nèi)核中，并在重新安排任務(wù)執(zhí)行時再次加載。這確保了任務(wù)的原始狀態(tài)不受影響，并且任務(wù)似乎在持續(xù)運行。

CPU 上下文切換的類型

你可能會說 CPU 上下文切換無非就是更新 CPU 寄存器和程序計數(shù)器值，而這些寄存器是為了快速運行任務(wù)而設(shè)計的，那為什么會影響 CPU 性能呢？

在回答這個問題之前，請問，你有沒有想過這些“任務(wù)”是什么？你可能會說一個任務(wù)就是一個進程或者一個線程。是的，進程和線程正是最常見的任務(wù)，但除此之外，還有其他類型的任務(wù)。

別忘了硬件中斷也是一個常見的任務(wù)，硬件觸發(fā)信號，會引起中斷處理程序的調(diào)用。

因此，CPU 上下文切換至少有三種不同的類型：

進程上下文切換

線程上下文切換

中斷上下文切換

讓我們一一來看看。

進程上下文切換

Linux 按照特權(quán)級別將進程的運行空間劃分為內(nèi)核空間和用戶空間，分別對應(yīng)下圖中Ring 0和Ring 3的 CPU 特權(quán)級別的 。

內(nèi)核空間（Ring 0）擁有最高權(quán)限，可以直接訪問所有資源。

用戶空間（Ring 3）只能訪問受限資源，不能直接訪問內(nèi)存等硬件設(shè)備，它必須通過系統(tǒng)調(diào)用被陷入（trapped）內(nèi)核中才能訪問這些特權(quán)資源。

從另一個角度看，一個進程既可以在用戶空間也可以在內(nèi)核空間運行。當一個進程在用戶空間運行時，稱為該進程的用戶態(tài)，當它落入內(nèi)核空間時，稱為該進程的內(nèi)核態(tài)。

從用戶態(tài)到內(nèi)核態(tài)的轉(zhuǎn)換需要通過系統(tǒng)調(diào)用來完成。例如，當我們查看一個文件的內(nèi)容時，我們需要以下系統(tǒng)調(diào)用：

open()：打開文件

read()：讀取文件的內(nèi)容

write()：將文件的內(nèi)容寫入到輸出文件（包括標準輸出）

close()：關(guān)閉文件

那么在上述系統(tǒng)調(diào)用過程中是否會發(fā)生 CPU 上下文切換呢？當然是的。

這需要先保存 CPU 寄存器中原來的用戶態(tài)指令的位置。接下來，為了執(zhí)行內(nèi)核態(tài)的代碼，需要將 CPU 寄存器更新到內(nèi)核態(tài)指令的新位置。最后是跳轉(zhuǎn)到內(nèi)核態(tài)運行內(nèi)核任務(wù)。

那么系統(tǒng)調(diào)用結(jié)束后，CPU 寄存器需要恢復(fù)原來保存的用戶狀態(tài)，然后切換到用戶空間繼續(xù)運行進程。

因此，在一次系統(tǒng)調(diào)用的過程中，實際上有兩次 CPU 上下文切換。

但需要指出的是，系統(tǒng)調(diào)用進程不會涉及進程切換，也不會涉及虛擬內(nèi)存等系統(tǒng)資源切換。這與我們通常所說的“進程上下文切換”不同。進程上下文切換是指從一個進程切換到另一個進程，而系統(tǒng)調(diào)用期間始終運行同一個進程。

系統(tǒng)調(diào)用過程通常被稱為特權(quán)模式切換，而不是上下文切換。但實際上，在系統(tǒng)調(diào)用過程中，CPU 的上下文切換也是不可避免的。

進程上下文切換 vs 系統(tǒng)調(diào)用

那么進程上下文切換和系統(tǒng)調(diào)用有什么區(qū)別呢？首先，進程是由內(nèi)核管理的，進程切換只能發(fā)生在內(nèi)核態(tài)。因此，進程上下文不僅包括虛擬內(nèi)存、棧和全局變量等用戶空間資源，還包括內(nèi)核棧和寄存器等內(nèi)核空間的狀態(tài)。

所以進程上下文切換比系統(tǒng)調(diào)用要多出一步：

在保存當前進程的內(nèi)核狀態(tài)和 CPU 寄存器之前，需要保存進程的虛擬內(nèi)存、棧等；并加載下一個進程的內(nèi)核狀態(tài)。

根據(jù) Tsuna 的測試報告，每次上下文切換需要幾十納秒至微秒的 CPU 時間。這個時間是相當可觀的，尤其是在大量進程上下文切換的情況下，很容易導(dǎo)致 CPU 花費大量時間來保存和恢復(fù)寄存器、內(nèi)核棧、虛擬內(nèi)存等資源。這正是我們在上一篇文章中談到的，一個導(dǎo)致平均負載上升的重要因素。

那么，該進程何時會被調(diào)度/切換到在 CPU 上運行？其實有很多場景，下面我為大家總結(jié)一下：

當一個進程的 CPU 時間片用完時，它會被系統(tǒng)掛起，并切換到其它等待 CPU 運行的進程。

當系統(tǒng)資源不足（如內(nèi)存不足）時，直到資源充足之前，進程無法運行。此時進程也會被掛起，系統(tǒng)會調(diào)度其它進程運行。

當一個進程通過 sleep函數(shù)自動掛起自己時，自然會被重新調(diào)度。

當優(yōu)先級較高的進程運行時，為了保證高優(yōu)先級進程的運行，當前進程會被高優(yōu)先級進程掛起運行。

當發(fā)生硬件中斷時，CPU上的進程會被中斷掛起，轉(zhuǎn)而執(zhí)行內(nèi)核中的中斷服務(wù)程序。

了解這些場景是非常有必要的，因為一旦上下文切換出現(xiàn)性能問題，它們就是幕后殺手。

線程上下文切換

線程和進程最大的區(qū)別在于，線程是任務(wù)調(diào)度的基本單位，而進程是資源獲取的基本單位。

說白了，內(nèi)核中所謂的任務(wù)調(diào)度，實際的調(diào)度對象是線程；而進程只為線程提供虛擬內(nèi)存和全局變量等資源。所以，對于線程和進程，我們可以這樣理解：

當一個進程只有一個線程時，可以認為一個進程等于一個線程。

當一個進程有多個線程時，這些線程共享相同的資源，例如虛擬內(nèi)存和全局變量。

此外，線程也有自己的私有數(shù)據(jù)，比如棧和寄存器，在上下文切換時也需要保存。

這樣，線程的上下文切換其實可以分為兩種情況：

首先，前后兩個線程屬于不同的進程。此時，由于資源不共享，切換過程與進程上下文切換相同。

其次，前后兩個線程屬于同一個進程。此時，由于虛擬內(nèi)存是共享的，所以切換時虛擬內(nèi)存的資源保持不變，只需要切換線程的私有數(shù)據(jù)、寄存器等未共享的數(shù)據(jù)。

顯然，同一個進程內(nèi)的線程切換比切換多個進程消耗的資源要少。這也是多線程替代多進程的優(yōu)勢。

中斷上下文切換

除了前面兩種上下文切換之外，還有另外一種場景也輸出 CPU 上下文切換的，那就是中斷。

為了快速響應(yīng)事件，硬件中斷會中斷正常的調(diào)度和執(zhí)行過程，進而調(diào)用中斷處理程序。

在中斷其他進程時，需要保存進程的當前狀態(tài)，以便中斷后進程仍能從原始狀態(tài)恢復(fù)。

與進程上下文不同，中斷上下文切換不涉及進程的用戶態(tài)。因此，即使中斷進程中斷了處于用戶態(tài)的進程，也不需要保存和恢復(fù)進程的虛擬內(nèi)存、全局變量等用戶態(tài)資源。

另外，和進程上下文切換一樣，中斷上下文切換也會消耗 CPU。過多的切換次數(shù)會消耗大量的 CPU 資源，甚至嚴重降低系統(tǒng)的整體性能。因此，當您發(fā)現(xiàn)中斷過多時，需要注意排查它是否會對您的系統(tǒng)造成嚴重的性能問題。

問題排查

工具

vmstat ——是一個常用的系統(tǒng)性能分析工具，主要用來分析系統(tǒng)的內(nèi)存使用情況，也常用來分析CPU上下文切換和中斷的次數(shù)。

pidstat ——vmstat只給出了系統(tǒng)總體的上下文切換情況，要想查看每個進程的詳細情況，就需要使用pidstat，加上-w，可以查看每個進程上下文切換的情況。

/proc/interrupts——/proc實際上是linux的虛擬文件系統(tǒng)用于內(nèi)核空間和用戶空間的通信，/proc/interrupts是這種通信機制的一部分，提供了一個只讀的中斷使用情況。

perf stat 可以統(tǒng)計很多和 CPU 相關(guān)核心數(shù)據(jù)，比如 cache' miss，上下文切換，CPI 等。

實 戰(zhàn)

vmstat:

#每隔1秒輸出1組數(shù)據(jù)（需要Ctrl+C才結(jié)束）
$vmstat1
procs-----------memory-------------swap-------io-----system--------cpu-----
rbswpdfreebuffcachesisobiboincsussyidwast
600648742811824012927720000901913988301684000
8006487428118240129277200001019113923121684000
cs（contextswitch）是每秒上下文切換的次數(shù)
in(interrupt)每秒中斷的次數(shù)
r (Running or Runnnable)是就緒隊列的長度，也就是正在運行和等待CPU的進程數(shù)。
b(Blocked)則是處于不可中斷睡眠狀態(tài)的進程數(shù)
分析：
查看cs大小（實驗時cs驟升到百萬）
同時注意r列（實驗時為8），機器cpu為1，遠遠超過1，必然會有大量的CPU競爭
us和sy列，計算cpu使用率總和（實驗加起來快100%，其中sy高達84%，說明cpu主要被內(nèi)核占用）
in列，查看大?。▽嶒炛畜E升到一萬，說明中斷處理也是潛在的問題）
綜合可知，系統(tǒng)的就需隊列過長，也就是正在運行和等待CPU的進程數(shù)過多，導(dǎo)致了大量的上下文切換，而上下文切換導(dǎo)致了cpu占用率高

pidstat查看進程上下文切換情況：

#每隔1秒輸出1組數(shù)據(jù)（需要Ctrl+C才結(jié)束）
#-w參數(shù)表示輸出進程切換指標，而-u參數(shù)則表示輸出CPU使用指標
$pidstat-w-u1
08:06:33UIDPID%usr%system%guest%wait%CPUCPUCommand
08:06:3401048830.00100.000.000.00100.000sysbench
08:06:340263260.001.000.000.001.000kworker/u4:2

08:06:33UIDPIDcswch/snvcswch/sCommand
08:06:340811.000.00rcu_sched
08:06:340161.000.00ksoftirqd/1
08:06:3404711.000.00hv_balloon
08:06:34012301.000.00iscsid
08:06:34040891.000.00kworker/1:5
08:06:34043331.000.00kworker/0:3
08:06:340104991.00224.00pidstat
08:06:34026326236.000.00kworker/u4:2
08:06:34100026784223.000.00sshd
cswch 表示每秒自愿上下文切換的次數(shù)，是指進程無法獲取所需資源，導(dǎo)致的上下文切換，比如說，I/O，內(nèi)存等系統(tǒng)資源不足時，就會發(fā)生自愿上下文切換。
nvcswch 表示每秒非自愿上下文切換的次數(shù)，則是指進程由于時間片已到等原因，被系統(tǒng)強制調(diào)度，進而發(fā)生的上下文切換。
分析：
pidstat查看果然是sysbench導(dǎo)致了cpu達到100%，但上下文切換來自其他進程，包括非自愿上下文切換最高的pidstat，以及自愿上下文切換最高的kworker和sshd
但pidtstat輸出的上下文切換次數(shù)加起來才幾百和vmstat的百萬明顯小很多，現(xiàn)在vmstat輸出的是線程，而pidstat加上-t后才輸出線程指標

#每隔1秒輸出一組數(shù)據(jù)（需要Ctrl+C才結(jié)束）
#-wt參數(shù)表示輸出線程的上下文切換指標
$pidstat-wt1
08:14:05UIDTGIDTIDcswch/snvcswch/sCommand
...
08:14:05010551-6.000.00sysbench
08:14:050-105516.000.00|__sysbench
08:14:050-1055218911.00103740.00|__sysbench
08:14:050-1055318915.00100955.00|__sysbench
08:14:050-1055418827.00103954.00|__sysbench
...
pidstat子線程加一起就差不多百萬了。

看中斷——可排查是哪些中斷引起的（變化速度最快的）：

#-d參數(shù)表示高亮顯示變化的區(qū)域
$watch-dcat/proc/interrupts
CPU0CPU1
...
RES:24504315279697Reschedulinginterrupts
...

觀察一段時間后，可以發(fā)現(xiàn)變化最快的是重新調(diào)度中斷（RES, REScheduling interrupt）。這種中斷類型表明處于空閑狀態(tài)的 CPU 被喚醒以調(diào)度新的任務(wù)運行。所以這里的中斷增加是因為太多的任務(wù)調(diào)度問題，這和前面上下文切換次數(shù)的分析結(jié)果是一致的。

現(xiàn)在回到最初的問題，每秒多少次上下文切換是正常的？

這個值實際上取決于系統(tǒng)本身的 CPU 性能。如果系統(tǒng)的上下文切換次數(shù)比較穩(wěn)定的話，幾百到一萬應(yīng)該是正常的。但是，當上下文切換次數(shù)超過10000，或者切換次數(shù)快速增加時，很可能是出現(xiàn)了性能問題。

perf stat 可以排查系統(tǒng)上下文切換速率變化：

可以觀察 context-switcehes 數(shù)據(jù)的變化，有沒有突增，可以發(fā)現(xiàn)一些異常想象。

場 景

根據(jù)調(diào)度策略，將 CPU 時間劃片為對應(yīng)的時間片，當時間片耗盡，當前進程必須掛起。

資源不足的，在獲取到足夠資源之前進程掛起。

進程 sleep 掛起進程。

高優(yōu)先級進程導(dǎo)致當前進度掛起。

硬件中斷，導(dǎo)致當前進程掛起。

小 結(jié)

CPU 上下文切換，是保證 Linux 系統(tǒng)正常工作的核心功能之一，一般情況下不需要我們特別關(guān)注。

但過多的上下文切換，會把 CPU 時間消耗在寄存器，內(nèi)核棧以及虛擬內(nèi)存等數(shù)據(jù)的保存和恢復(fù)上，從而縮短進程真正運行的時間，導(dǎo)致系統(tǒng)的整體性能大幅下降。

自愿上下文切換變多了，說明進程都在等待資源，有可能發(fā)生了 I/O 等其他問題。

非自愿上下文切換變多了，說明進程都在被強制調(diào)度，也就是都在爭搶 CPU，說明 CPU 的確成了瓶頸。

中斷次數(shù)變多了，說明 CPU 被中斷處理程序占用，還需要通過查看 /proc/interrupts 文件來分析具體的中斷類型。

審核編輯 ：李倩