色哟哟视频在线观看-色哟哟视频在线-色哟哟欧美15最新在线-色哟哟免费在线观看-国产l精品国产亚洲区在线观看-国产l精品国产亚洲区久久

0
  • 聊天消息
  • 系統消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發帖/加入社區
會員中心
創作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

詳細解讀Linux CPU的上下文切換過程

嵌入式情報局 ? 來源:嵌入式情報局 ? 作者:嵌入式情報局 ? 2023-02-09 15:30 ? 次閱讀

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

eda2fc06-a848-11ed-bfe3-dac502259ad0.png

CPU 上下文(CPU Context)

在每個任務運行之前,CPU 需要知道在哪里加載和啟動任務。這意味著系統需要提前幫助設置 CPU 寄存器和程序計數器。

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

它們都是 CPU 在運行任何任務之前必須依賴的依賴環境,因此也被稱為 “CPU 上下文”。如下圖所示:

edc7f6f0-a848-11ed-bfe3-dac502259ad0.png

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

這些保存的上下文存儲在系統內核中,并在重新安排任務執行時再次加載。這確保了任務的原始狀態不受影響,并且任務似乎在持續運行。

CPU 上下文切換的類型

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

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

別忘了硬件中斷也是一個常見的任務,硬件觸發信號,會引起中斷處理程序的調用。

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

進程上下文切換

線程上下文切換

中斷上下文切換

讓我們一一來看看。

進程上下文切換

Linux 按照特權級別將進程的運行空間劃分為內核空間和用戶空間,分別對應下圖中Ring 0和Ring 3的 CPU 特權級別的 。

內核空間(Ring 0)擁有最高權限,可以直接訪問所有資源。

用戶空間(Ring 3)只能訪問受限資源,不能直接訪問內存等硬件設備,它必須通過系統調用陷入(trapped)內核中才能訪問這些特權資源。

edd52334-a848-11ed-bfe3-dac502259ad0.png

從另一個角度看,一個進程既可以在用戶空間也可以在內核空間運行。當一個進程在用戶空間運行時,稱為該進程的用戶態,當它落入內核空間時,稱為該進程的內核態。

從用戶態到內核態的轉換需要通過系統調用來完成。例如,當我們查看一個文件的內容時,我們需要以下系統調用:

open():打開文件

read():讀取文件的內容

write():將文件的內容寫入到輸出文件(包括標準輸出)

close():關閉文件

那么在上述系統調用過程中是否會發生 CPU 上下文切換呢?當然是的。

這需要先保存 CPU 寄存器中原來的用戶態指令的位置。接下來,為了執行內核態的代碼,需要將 CPU 寄存器更新到內核態指令的新位置。最后是跳轉到內核態運行內核任務。

那么系統調用結束后,CPU 寄存器需要恢復原來保存的用戶狀態,然后切換到用戶空間繼續運行進程。

因此,在一次系統調用的過程中,實際上有兩次 CPU 上下文切換。

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

系統調用過程通常被稱為特權模式切換,而不是上下文切換。但實際上,在系統調用過程中,CPU 的上下文切換也是不可避免的。

進程上下文切換 vs 系統調用

那么進程上下文切換和系統調用有什么區別呢?首先,進程是由內核管理的,進程切換只能發生在內核態。因此,進程上下文不僅包括虛擬內存、棧和全局變量等用戶空間資源,還包括內核棧和寄存器等內核空間的狀態。

所以進程上下文切換比系統調用要多出一步:

在保存當前進程的內核狀態和 CPU 寄存器之前,需要保存進程的虛擬內存、棧等;并加載下一個進程的內核狀態。

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

那么,該進程何時會被調度/切換到在 CPU 上運行?其實有很多場景,下面我為大家總結一下:

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

當系統資源不足(如內存不足)時,直到資源充足之前,進程無法運行。此時進程也會被掛起,系統會調度其它進程運行。

當一個進程通過 sleep函數自動掛起自己時,自然會被重新調度。

當優先級較高的進程運行時,為了保證高優先級進程的運行,當前進程會被高優先級進程掛起運行

當發生硬件中斷時,CPU上的進程會被中斷掛起,轉而執行內核中的中斷服務程序。

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

線程上下文切換

線程和進程最大的區別在于,線程是任務調度的基本單位,而進程是資源獲取的基本單位。

說白了,內核中所謂的任務調度,實際的調度對象是線程;而進程只為線程提供虛擬內存和全局變量等資源。所以,對于線程和進程,我們可以這樣理解:

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

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

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

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

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

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

顯然,同一個進程內的線程切換比切換多個進程消耗的資源要少。這也是多線程替代多進程的優勢。

中斷上下文切換

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

為了快速響應事件,硬件中斷會中斷正常的調度和執行過程,進而調用中斷處理程序。

在中斷其他進程時,需要保存進程的當前狀態,以便中斷后進程仍能從原始狀態恢復。

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

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

問題排查

工具

vmstat ——是一個常用的系統性能分析工具,主要用來分析系統的內存使用情況,也常用來分析CPU上下文切換和中斷的次數。


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


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

perf stat 可以統計很多和 CPU 相關核心數據,比如 cache' miss,上下文切換,CPI 等。

實 戰

vmstat:

#每隔1秒輸出1組數據(需要Ctrl+C才結束)
$vmstat1
procs-----------memory-------------swap-------io-----system--------cpu-----
rbswpdfreebuffcachesisobiboincsussyidwast
600648742811824012927720000901913988301684000
8006487428118240129277200001019113923121684000
cs(contextswitch)是每秒上下文切換的次數
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占用率高

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

#每隔1秒輸出1組數據(需要Ctrl+C才結束)
#-w參數表示輸出進程切換指標,而-u參數則表示輸出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 表示每秒自愿上下文切換的次數,是指進程無法獲取所需資源,導致的上下文切換,比如說,I/O,內存等系統資源不足時,就會發生自愿上下文切換。
nvcswch 表示每秒非自愿上下文切換的次數,則是指進程由于時間片已到等原因,被系統強制調度,進而發生的上下文切換。
分析:
pidstat查看果然是sysbench導致了cpu達到100%,但上下文切換來自其他進程,包括非自愿上下文切換最高的pidstat,以及自愿上下文切換最高的kworker和sshd
但pidtstat輸出的上下文切換次數加起來才幾百和vmstat的百萬明顯小很多,現在vmstat輸出的是線程,而pidstat加上-t后才輸出線程指標

#每隔1秒輸出一組數據(需要Ctrl+C才結束)
#-wt參數表示輸出線程的上下文切換指標
$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參數表示高亮顯示變化的區域
$watch-dcat/proc/interrupts
CPU0CPU1
...
RES:24504315279697Reschedulinginterrupts
...

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

現在回到最初的問題,每秒多少次上下文切換是正常的?

這個值實際上取決于系統本身的 CPU 性能。如果系統的上下文切換次數比較穩定的話,幾百到一萬應該是正常的。但是,當上下文切換次數超過10000,或者切換次數快速增加時,很可能是出現了性能問題。

perf stat 可以排查系統上下文切換速率變化:

edf86574-a848-11ed-bfe3-dac502259ad0.png

可以觀察 context-switcehes 數據的變化,有沒有突增,可以發現一些異常想象。

場 景

根據調度策略,將 CPU 時間劃片為對應的時間片,當時間片耗盡,當前進程必須掛起。

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

進程 sleep 掛起進程。

高優先級進程導致當前進度掛起。

硬件中斷,導致當前進程掛起。

小 結

CPU 上下文切換,是保證 Linux 系統正常工作的核心功能之一,一般情況下不需要我們特別關注。

但過多的上下文切換,會把 CPU 時間消耗在寄存器,內核棧以及虛擬內存等數據的保存和恢復上,從而縮短進程真正運行的時間,導致系統的整體性能大幅下降。

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

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

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

審核編輯 :李倩

聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人,不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規問題,請聯系本站處理。 舉報投訴
  • cpu
    cpu
    +關注

    關注

    68

    文章

    10878

    瀏覽量

    212167
  • Linux
    +關注

    關注

    87

    文章

    11319

    瀏覽量

    209830
  • 計數器
    +關注

    關注

    32

    文章

    2256

    瀏覽量

    94700

原文標題:詳細解讀 Linux CPU的上下文切換過程

文章出處:【微信號:嵌入式情報局,微信公眾號:嵌入式情報局】歡迎添加關注!文章轉載請注明出處。

收藏 人收藏

    評論

    相關推薦

    編寫一個任務調度程序,在上下文切換后遇到了一些問題求解

    \"rfe\" 不會在 A[11] 寄存器中設置新的返回地址。 當任務函數以\"ret16\" 結束時,μC 將在陷阱中運行。 我在上下文切換的準備過程中錯過了什么? 在上下文切換/\"rfe\" 之后,A[11] 的正確行為是
    發表于 05-22 07:50

    關于進程上下文、中斷上下文及原子上下文的一些概念理解

    : 進程控制塊task_struct、內存管理信息(mm_struct、vm_area_struct、pgd、pte)、內核棧。 當發生進程調度時,進行進程切換就是上下文切換(context switch
    發表于 09-06 09:58

    BT堆棧上下文切換

    100ms就會產生一個上下文切換上下文切換每秒似乎有點高。我想我真的不能抱怨10個開關,但是有什么東西嗎?在BT協議中真的需要這個嗎?不能處理中斷驅動嗎?(這是BT是可連接的,但既沒有連接,也沒有
    發表于 12-17 16:30

    多線程如何實現上下文切換

    處理系統中,CPU需要處理所有程序的操作,當用戶來回切換它們時,需要記錄這些程序執行到哪里。上下文切換就是這樣一個過程,他允許CPU記錄并恢
    發表于 08-02 08:21

    上下文切換簡介

    處理系統中,CPU需要處理所有程序的操作,當用戶來回切換它們時,需要記錄這些程序執行到哪里。上下文切換就是這樣一個過程,他允許CPU記錄并恢
    發表于 08-06 08:08

    上下文切換的情況發生

    處理系統中,CPU需要處理所有程序的操作,當用戶來回切換它們時,需要記錄這些程序執行到哪里。上下文切換就是這樣一個過程,他允許CPU記錄并恢
    發表于 08-07 08:38

    ucos上下文該怎么切換

    有兩個問題請教一下大神!!!-->1在ucos中的上下文切換時發生在pendSV異常中,代碼見下:PendSV_Handler CPSIDI; Prevent interruption
    發表于 08-26 03:21

    討論ARM mbed OS(RTX) 的上下文切換

    來說,本文是一個回顧和總結,如我在《淺談調度相關的元問題》一文所述,mbed OS 是一個支持分態的內核,其上下文切換實現的套路非常神似 linux,故而對 mbed OS 上下文切換的探討有一定的推廣
    發表于 02-16 14:26

    rt-thread上下文切換函數的意義在哪?

    Cortex-M3內核上下文切換函數rt_hw_context_switch()/ rt_hw_context_switch_interrupt()中有個判斷rt_thread_switch_interrupt_flag的地方,不知道意義在哪?
    發表于 03-10 11:28

    中斷中的上下文切換詳解

    ();  /* 發起一次在中斷中的上下文切換 */  cpu_irq_context_switch();  }  tos_knl_irq_enter接口(進入ISR時調用)將一個標識中斷嵌套次數的變量
    發表于 03-23 17:18

    CPU上下文切換詳細資料講解

    當UCOS-III轉向執行另一項新任務的時候,他保存了當前任務的CPU寄存器到堆棧,并從新任務的堆棧CPU寄存器載入CPU,這個過程叫做上下文切換
    發表于 08-16 17:31 ?2次下載
    <b class='flag-5'>CPU</b><b class='flag-5'>上下文切換</b>的<b class='flag-5'>詳細</b>資料講解

    如何分析Linux CPU上下文切換問題

    在我的上一篇文章:《探討 Linux CPU上下文切換》中,我談到了 CPU 上下文切換的工作原理。快速回顧一下,
    的頭像 發表于 05-05 20:11 ?1969次閱讀

    Linux CPU上下文切換

    我們都知道 Linux 是一個多任務操作系統,它支持的任務同時運行的數量遠遠大于 CPU 的數量。當然,這些任務實際上并不是同時運行的(Single CPU),而是因為系統在短時間內將 CPU
    的頭像 發表于 02-15 14:44 ?608次閱讀
    <b class='flag-5'>Linux</b> <b class='flag-5'>CPU</b><b class='flag-5'>上下文切換</b>

    Linux技術:什么是cpu上下文切換

    過多的上下文切換會消耗 CPU 的時間來保存和恢復寄存器、程序計數器、內核棧和虛擬內存等數據,從而導致系統性能顯著下降。 既然上下文切換對系統性能的影響如此之大,那么我們如何檢查它呢?好了,你可以使用 vmstat 工具來查詢你
    發表于 09-01 09:31 ?487次閱讀
    <b class='flag-5'>Linux</b>技術:什么是<b class='flag-5'>cpu</b><b class='flag-5'>上下文切換</b>

    FreeRTOS系列技術文章:上下文切換

    嵌入式實時操作系統(RTOS)中的上下文切換是指保存和恢復任務的狀態,以使調度程序能夠切換到另一個任務,從而促進多任務處理。
    的頭像 發表于 11-21 15:48 ?1190次閱讀
    主站蜘蛛池模板: 亚洲男人的天堂久久精品麻豆| 色屁屁影院| 国产精品女上位在线观看| SM高H黄暴NP辣H调教性奴| 2012中文字幕手机在线| 一本大道熟女人妻中文字幕在线| 亚洲电影第1页| 天天爽夜夜爽| 色偷偷亚洲男人天堂| 日本高清色片| 日本888 xxxx| 日本阿v片在线播放免费| 青草久久精品亚洲综合专区| 欧美性爱 成人| 欧美特级另类xxx| 秋霞电影院午夜伦高清| 日本G奶乳液汁| 日日干夜夜艹| 微福利92合集| 亚洲大片在线观看| 亚洲欧洲免费三级网站| 亚洲中文在线精品国产| 与子敌伦刺激对白亂輪亂性| 中文字幕精品AV内射夜夜夜| 777精品久无码人妻蜜桃| 99热在线观看精品| 扒开美女的内衣亲吻漫画| 电影日本妻子| 国产久久热99视频| 韩剧甜性涩爱| 久久伊人草| 嗯 用力啊 嗯 c我 啊哈老师| 朋友的娇妻好爽好烫嗯| 色 花 堂 永久 网站| 亚州日韩精品AV片无码中文| 亚洲精品无码午夜福利在线观看| 亚洲中文久久久久久国产精品 | 19十主播福利视频| HEYZO精品无码一区二区三区| 草神被爆漫画羞羞漫画| 国产精品VIDEOS麻豆TUBE|