CPU上下文切換的次數和時間（context switch）
什麽是CPU上下文切換？
現在linux是大多基於搶占式，CPU給每個任務一定的服務時間，當時間片輪轉的時候，需要把當前狀態保存下來，同時加載下一個任務，這個過程叫做上下文切換。時間片輪轉的方式，使得多個任務利用一個CPU執行成為可能，但是保存現場和加載現場，也帶來了性能消耗。 那線程上下文切換的次數和時間以及性能消耗如何看呢？
? ?如何獲得上下文切換的次數？
vmstat直接運行即可，在最後幾列，有CPU的context switch次數。 這個是系統層面的，加入想看特定進程的情況，可以使用pidstat。
| 1 2 3 4 5 6 7 |
$ vmstat 1 100
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 88 233484 288756 1784744 0 0 0 23 0 0 4 1 94 0 0
4 0 88 233236 288756 17847520 0 0 0 6202 7880 4 1 96 0 0
2 0 88 233360 288756 1784800 0 0 0 112 6277 7612 4 1 95 0 0
0 0 88 232864 288756 1784804 0 0 0 644 5747 6593 6 0 92 2 0
|
? ?執行pidstat，將輸出系統啟動後所有活動進程的cpu統計信息： ?
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
linux:~ # pidstatLinux 2.6.32.12-0.7-default (linux) 06/18/12 _x86_64_
11:37:19 PID %usr %system %guest %CPU CPU Command
……
11:37:19 11452 0.00 0.00 0.00 0.00 2 bash
11:37:19 11509 0.00 0.00 0.00 0.00 3 dd
11:37:19: pidstat獲取信息時間點
PID: 進程pid
%usr: 進程在用戶態運行所占cpu時間比率
%system: 進程在內核態運行所占cpu時間比率
%CPU: 進程運行所占cpu時間比率
CPU: 指示進程在哪個核運行
Command: 拉起進程對應的命令
備註:執行pidstat默認輸出信息為系統啟動後到執行時間點的統計信息，因而即使當前某進程的cpu占用率很高，輸出中的值有可能仍為0。
|
? ?
? ??上下文切換的性能消耗在哪裏呢？
? ?context switch過高，會導致CPU像個搬運工，頻繁在寄存器和運行隊列直接奔波 ，更多的時間花在了線程切換，而不是真正工作的線程上。直接的消耗包括CPU寄存器需要保存和加載，系統調度器的代碼需要執行。間接消耗在於多核cache之間的共享數據。
?
? ?引起上下文切換的原因有哪些？
? ?對於搶占式操作系統而言， 大體有幾種：
? ?1、當前任務的時間片用完之後，系統CPU正常調度下一個任務；
? ?2、當前任務碰到IO阻塞，調度線程將掛起此任務，繼續下一個任務；
? ?3、多個任務搶占鎖資源，當前任務沒有搶到，被調度器掛起，繼續下一個任務；
? ?4、用戶代碼掛起當前任務，讓出CPU時間；
? ?5、硬件中斷；
? ?
? ?如何測試上下文切換的時間消耗？
LMbench，知道這個工具，是在霸爺的博客上面（http://blog.yufeng.info/archives/753），然後就開始在測試環境下搞了一把，一會就出結果了。然後就搞了臺線上機器安裝這個工具，然後測試，後面在測試Memory的時候，直接導致Load飆升，還好沒人發現，機器java進程重啟就好了。這方面純粹是業務選手。霸爺說分析的結果對於高性能C的開發同學來說，是需要熟記的，沒辦法，咱是搞java的，只能每個指標逐個看一下了。
?
? ?LMbench的簡單介紹？
? 首先看英文介紹：LMbench -Tools for Performance Analysis，微觀性能分析工具。
? 官方地址：http://www.bitmover.com/lmbench/
?下載地址：http://www.bitmover.com/lmbench/lmbench3.tar.gz
? ?LMbench?主要能幹啥？
?主要是帶寬（讀取緩存文件、內存拷貝、讀寫內存、管道等）和反應時間（上下文切換、網路、進程創建等）的評測工具。
? ? LMbench ?安裝？
| 1 2 3 4 |
#wget http://www.bitmover.com/lmbench/lmbench3.tar.gz
#tar -zxvf lmbench3.tar.gz
#cd lmbench3
#make
|
?中間遇到一個問題，就是報錯，在CSDN上面找到了答案，這這裏貼一下。
| 1 2 3 4 5 6 7 8 9 10 11 |
此時會報錯：
make[2]: *** 沒有規則可以創建“bk.ver”需要的目標“../SCCS/s.ChangeSet”。 停止。
make[2]:正在離開目錄 `/home/hero/lmbench3/src‘
make[1]: *** [lmbench] 錯誤 2
make[1]:正在離開目錄 `/home/hero/lmbench3/src‘
make: *** [build] 錯誤 2
解決辦法：
lmbench3目錄下
#mkdir SCCS
#touch ./SCCS/s.ChangeSet
#make
|
? ? LMbench關於結果解釋（這次主要關註線程切換信息）
在網上找了半天，信息很少，只能看doc下面的英文解釋了。
測試上下文切換的時間，一個上下文切換，包括保存一個進程狀態的保存和恢復另外一個進程的時間。
典型的上下文切換性能，僅僅是測量最小的線程切換時間。僅僅是做進程切換，任何實質的任務都不做。
| 1 2 3 4 5 6 |
Context switching - times in microseconds - smaller is better
-------------------------------------------------------------------------
Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw
--------- ------------- ------ ------ ------ ------ ------ ------- -------
commonway Linux 2.6.18- 9.2400 4.0200 9.0300 7.5600 8.3800 11.6 6.28000
時間的單位是微秒。
|
?
LMbench是如何來測量進程切換的時間的？
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
The benchmark is a ring of two to twenty processes that are connected
with Unix pipes. A token is passed from process to process, forcing
context switches. The benchmark measures the time it takes to pass
the token two thousand times from process to process. Each hand off
of the token has two costs: (a) the context switch, and (b) the cost
of passing the token. In order to get just the context switching time,the benchmark first measures the cost of passing the token through a
ring of pipes in a single process. This time is defined as the cost
of passing the token and is not included in the reported context switch
time.
.PP
When the processes are larger than the default baseline of ``zero‘‘
(where zero means just big enough to do the benchmark), the cost
of the context switch includes the cost of restoring user level
state (cache lines). This is accomplished by having the process
allocate an array of data and sum it as a series of integers
after receiving the token but before passing the token to the
next process. Note that the overhead mentioned above includes
the cost of accessing the data but because it is measured in
just one address space, the cost is typically the cost with hot
caches. So the context switch time does not include anything
other than the context switch provided that all the processes
fit in the cache. If there are cache misses (as is common), the
cost of the context switch includes the cost of those cache misses.
.PP
首先是看任務處理的時間（通過一次任務處理，這個任務處理的時間被定義為token時間，不包括線程切換的）。
然後多次執行，排除任務執行的時間，然後計算出CS的時間（如果有cache miss，則CS的時間也包括cache misses的時間）。
|
文章參考：
霸爺和周忱的博客
http://www.bitmover.com/lmbench/
https://www.usenix.org/legacy/publications/library/proceedings/sd96/full_papers/mcvoy.pdf
http://blog.csdn.net/taozi343805436/article/details/7876087
http://blog.yufeng.info/archives/753
http://rdc.taobao.com/team/jm/archives/1706
CPU上下文切換的次數和時間（context switch）