91欧美超碰AV自拍|国产成年人性爱视频免费看|亚洲 日韩 欧美一厂二区入|人人看人人爽人人操aV|丝袜美腿视频一区二区在线看|人人操人人爽人人爱|婷婷五月天超碰|97色色欧美亚州A√|另类A√无码精品一级av|欧美特级日韩特级

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

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

3天內(nèi)不再提示

當 CPU 空閑時它都在做什么?

5RJg_mcuworld ? 來源:未知 ? 作者:楊鑫 ? 2018-03-06 15:43 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

操作系統(tǒng)行為的基本原理是,在任何一個給定的時刻,在一個 CPU 上有且只有一個任務是活動的。但是,如果 CPU 無事可做的時候,又會是什么樣的呢?

事實證明,這種情況是非常普遍的,對于絕大多數(shù)的個人電腦來說,這確實是一種常態(tài):大量的睡眠進程,它們都在等待某種情況下被喚醒,差不多在 100% 的 CPU 時間中,都處于虛構的“空閑任務”中。事實上,如果一個普通用戶的 CPU 處于持續(xù)的繁忙中,它可能意味著有一個錯誤、bug、或者運行了惡意軟件。

因為我們不能違反我們的原理,一些任務需要在一個 CPU 上激活。首先是因為,這是一個良好的設計:持續(xù)很長時間去遍歷內(nèi)核,檢查是否有一個活動任務,這種特殊情況是不明智的做法。最好的設計是沒有任何例外的情況。無論何時,你寫一個 if 語句,Nyan Cat 就會喵喵喵。其次,我們需要使用空閑的 CPU 去做一些事情,讓它們充滿活力,你懂得,就是創(chuàng)建天網(wǎng)計劃唄。

因此,保持這種設計的連續(xù)性,并領先于那些邪惡計劃一步,操作系統(tǒng)開發(fā)者創(chuàng)建了一個空閑任務,當沒有其它任務可做時就調(diào)度它去運行。我們可以在 Linux 的 引導過程 中看到,這個空閑任務就是進程 0,它是由計算機打開電源時運行的第一個指令直接派生出來的。它在 rest_init 中初始化,在 init_idle_bootup_task 中初始化空閑調(diào)度類scheduling class。

簡而言之,Linux 支持像實時進程、普通用戶進程等等的不同調(diào)度類。當選擇一個進程變成活動任務時,這些類按優(yōu)先級進行查詢。通過這種方式,核反應堆的控制代碼總是優(yōu)先于 web 瀏覽器運行。盡管在通常情況下,這些類返回 NULL,意味著它們沒有合適的任務需要去運行 —— 它們總是處于睡眠狀態(tài)。但是空閑調(diào)度類,它是持續(xù)運行的,從不會失?。核偸欠祷乜臻e任務。

好吧,我們來看一下這個空閑任務到底做了些什么。下面是 cpu_idle_loop,感謝開源能讓我們看到它的代碼:

cpu_idle_loop

我省略了很多的細節(jié),稍后我們將去了解任務切換,但是,如果你閱讀了這些源代碼,你就會找到它的要點:由于這里不需要重新調(diào)度(即改變活動任務),它一直處于空閑狀態(tài)。以所經(jīng)歷的時間來計算,這個循環(huán)和其它操作系統(tǒng)中它的“堂兄弟們”相比,在計算的歷史上它是運行的最多的代碼片段。對于 Intel 處理器來說,處于空閑狀態(tài)意味著運行著一個 halt 指令:

native_halt

hlt 指令停止處理器中的代碼執(zhí)行,并將它置于 halt 的狀態(tài)。奇怪的是,全世界各地數(shù)以百萬計的 Intel 類的 CPU 們花費大量的時間讓它們處于 halt 的狀態(tài),甚至它們在通電的時候也是如此。這并不是高效、節(jié)能的做法,這促使芯片制造商們?nèi)ラ_發(fā)處理器的深度睡眠狀態(tài),以帶來著更少的功耗和更長休眠時間。內(nèi)核的 cpuidle 子系統(tǒng) 是這些節(jié)能模式能夠產(chǎn)生好處的原因。

現(xiàn)在,一旦我們告訴 CPU 去 halt(睡眠)之后,我們需要以某種方式讓它醒來。如果你讀過 上篇文章《你的操作系統(tǒng)什么時候運行?》 ,你可能會猜到中斷會參與其中,而事實確實如此。中斷促使 CPU 離開 halt 狀態(tài)返回到激活狀態(tài)。因此,將這些拼到一起,下圖是當你閱讀一個完全呈現(xiàn)的 web 網(wǎng)頁時,你的系統(tǒng)主要做的事情:

定時器中斷外的其它中斷也會使處理器再次發(fā)生變化。如果你再次點擊一個 web 頁面就會產(chǎn)生這種變化,例如:你的鼠標發(fā)出一個中斷,它的驅(qū)動會處理它,并且因為它產(chǎn)生了一個新的輸入,突然進程就可運行了。在那個時刻, need_resched() 返回 true,然后空閑任務因你的瀏覽器而被踢出而終止運行。

如果我們呆呆地看著這篇文章,而不做任何事情。那么隨著時間的推移,這個空閑循環(huán)就像下圖一樣:

在這個示例中,由內(nèi)核計劃的定時器中斷會每 4 毫秒發(fā)生一次。這就是滴答tick周期。也就是說每秒鐘將有 250 個滴答,因此,這個滴答速率(頻率)是 250 Hz。這是運行在 Intel 處理器上的 Linux 的典型值,而其它操作系統(tǒng)喜歡使用 100 Hz。這是由你構建內(nèi)核時在 CONFIG_HZ 選項中定義的。

對于一個空閑 CPU 來說,它看起來似乎是個無意義的工作。如果外部世界沒有新的輸入,在你的筆記本電腦的電池耗盡之前,CPU 將始終處于這種每秒鐘被喚醒 250 次的地獄般折磨的小憩中。如果它運行在一個虛擬機中,那我們正在消耗著宿主機 CPU 的性能和寶貴的時鐘周期。

在這里的解決方案是 動態(tài)滴答,當 CPU 處于空閑狀態(tài)時,定時器中斷被 暫?;蛑赜媱潱钡絻?nèi)核知道將有事情要做時(例如,一個進程的定時器可能要在 5 秒內(nèi)過期,因此,我們不能再繼續(xù)睡眠了),定時器中斷才會重新發(fā)出。這也被稱為無滴答模式。

最后,假設在一個系統(tǒng)中你有一個活動進程,例如,一個長時間運行的 CPU 密集型任務。那樣幾乎就和一個空閑系統(tǒng)是相同的:這些示意圖仍然是相同的,只是將空閑任務替換為這個進程,并且相應的描述也是準確的。在那種情況下,每 4 毫秒去中斷一次任務仍然是無意義的:它只是操作系統(tǒng)的性能抖動,甚至會使你的工作變得更慢而已。Linux 也可以在這種單一進程的場景中停止這種固定速率的滴答,這被稱為 自適應滴答 模式。最終,這種固定速率的滴答可能會 完全消失。

對于閱讀一篇文章來說,CPU 基本是無事可做的。內(nèi)核的這種空閑行為是操作系統(tǒng)難題的一個重要部分,并且它與我們看到的其它情況非常相似,因此,這將幫助我們理解一個運行中的內(nèi)核。

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

    關注

    68

    文章

    11281

    瀏覽量

    225097

原文標題:當 CPU 空閑時它都在做什么?

文章出處:【微信號:mcuworld,微信公眾號:嵌入式資訊精選】歡迎添加關注!文章轉(zhuǎn)載請注明出處。

收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評論

    相關推薦
    熱點推薦

    貼片都在哪里做的?

    你們貼片都在哪里做的?
    發(fā)表于 02-26 18:02

    CPU空閑時溫度為 50° 攝氏度這正常嗎?

    大家好 空閑時 CPU 溫度為 50°。 硬件: VF2 1.2A 8GB Waveshare VisionFive2 CPU 散熱風扇 注意:尚未涂抹導熱膏或?qū)釅|。 由于我沒有使用這些墊子的經(jīng)驗,因此將不勝感激建議
    發(fā)表于 02-11 08:20

    FreeRTOS 空閑任務

    FreeRTOS 中很多人會注意到為什么有一個叫IDLE task的任務占用了CPU百分之九十多的使用權,但是這個任務并沒有自己手動創(chuàng)建。原因就是這個空閑任務是系統(tǒng)自己創(chuàng)建的,每當系統(tǒng)沒有其他任務要運行時
    發(fā)表于 12-04 07:35

    串口空閑中斷與串口超時中斷介紹

    1. 空閑中斷(Idle Interrupt) 觸發(fā)條件 串口總線在接收數(shù)據(jù)后持續(xù)保持空閑狀態(tài)(如高電平)超過一幀時間(即一個字符傳輸時間)時觸發(fā)。 硬件自動檢測總線空閑狀態(tài),與數(shù)據(jù)
    發(fā)表于 11-21 08:31

    USART RX引腳的配置

    。 優(yōu)點:節(jié)省硬件成本,減少電路復雜度。 2. 上拉輸入 推薦場景: 長距離通信:線纜較長或環(huán)境存在電磁干擾時,上拉電阻可穩(wěn)定空閑狀態(tài)電平。 協(xié)議要求:USART協(xié)議規(guī)定總線空閑時為高電平,上拉確保RX
    發(fā)表于 11-20 08:23

    USART RX引腳應該上拉還是浮空?

    電阻(如4.7kΩ~10kΩ)可穩(wěn)定空閑狀態(tài)電平。 開漏/開集電極輸出:若發(fā)送端TX為開漏輸出(如某些I2C設備),必須通過上拉提供高電平。 協(xié)議要求:USART協(xié)議規(guī)定總線空閑時為高電平,上拉確保RX
    發(fā)表于 11-19 06:14

    MSP430FR2433的SPI通信為什么收不到?

    (幾乎是和時鐘一同跳變) 2、2355上MOSI在時鐘空閑時始終為低,而2433在空閑時會保持發(fā)送的最后一位電平(如圖) 有沒有高手能指點一二看看怎么解決
    發(fā)表于 11-18 20:31

    串口空閑中斷原理和特點

    空閑中斷 (Idle Interrupt): 觸發(fā)條件: 串口接收數(shù)據(jù)線(RX)從有數(shù)據(jù)傳輸?shù)臓顟B(tài)(低電平)進入并保持高電平狀態(tài)(即“空閑”狀態(tài))超過一個完整數(shù)據(jù)幀的時間(通常是 1 個字
    發(fā)表于 11-13 08:11

    空閑線程堆棧出現(xiàn)內(nèi)存溢出的問題,怎么解決?

    rtthread版本: 5.1.0 硬件: stm32f407vgt6 具體我也不知道什么原因引起的, 目前將堆棧調(diào)到1024后能為穩(wěn)定運行 更新 設置1024堆棧, 運行久了也不行 我有什么操作會影響到空閑線程?
    發(fā)表于 10-11 10:36

    電子工程師上班都在做什么?

    行業(yè)資訊
    揚興科技
    發(fā)布于 :2025年08月22日 18:24:07

    STM32407使用串口閑時中斷+DMA方式接收最大接收字節(jié)是多少?

    使用串口閑時中斷+DMA方式接收數(shù)據(jù),波特率為460800,DMA接收長度為1024個字節(jié),并開啟串口閑時中斷,當上位機一次發(fā)送520個字節(jié),我發(fā)現(xiàn)串口產(chǎn)生了兩次中斷,第一次接收的最大字節(jié)為272
    發(fā)表于 07-22 08:16

    什么是STM32? STM32與ARM有什么關系? STM32能做什么?

    什么是STM32 具體用于什么方面較多?? STM32與ARM有什么關系 STM32能做什么,簡單的比如調(diào)節(jié)協(xié)議,為什么那么久的產(chǎn)品到現(xiàn)在還是主流?
    發(fā)表于 06-23 17:34

    為什么 KT142C 芯片 BUSY 腳空閑高電平僅 0.2V?附低功耗模式配置指南

    文檔圍繞 KT142C 芯片 busy 引腳展開,該引腳為 15 腳 PA12,播放時輸出低電平,空閑時本應輸出 3.3V 高電平,但芯片空閑 5 秒進入 2μA 超低功耗狀態(tài)后,busy 腳呈高阻
    的頭像 發(fā)表于 06-16 09:38 ?1313次閱讀
    為什么 KT142C 芯片 BUSY 腳<b class='flag-5'>空閑</b>高電平僅 0.2V?附低功耗模式配置指南

    一個帶有CYPD3177的自定義COOLDIM_PRG_BOARD,翻轉(zhuǎn)時,則沒有POWER_DRILL2GO,為什么?

    我有一個帶有 CYPD3177 的自定義COOLDIM_PRG_BOARD 。 插入時,僅從POWER_DRILL2GO電源接收POWER_DRILL2GO信號,并且 USB 電纜處于一個方向
    發(fā)表于 05-26 07:24

    使用串口dma環(huán)形接收+空閑中斷,觸發(fā)空閑中斷后進入任務中拷貝數(shù)據(jù)發(fā)現(xiàn)拷貝的數(shù)據(jù)全為0,怎么處理?

    求助,我使用串口dma環(huán)形接收+空閑中斷,默認應該開了緩存,在觸發(fā)空閑中斷后進入任務中拷貝數(shù)據(jù)發(fā)現(xiàn)拷貝的數(shù)據(jù)全為0,但是我掛上調(diào)試之后在拷貝之前只要打上斷點斷一次執(zhí)行之后再執(zhí)行就正常了,該怎么處理,串口中斷內(nèi)有__dsb
    發(fā)表于 03-27 06:17