最美情侣中文字幕电影,在线麻豆精品传媒,在线网站高清黄,久久黄色视频

歡迎光臨散文網(wǎng) 會(huì)員登陸 & 注冊(cè)

【知乎】CPU 的工作原理是什么?

2023-07-03 00:08 作者:失傳技術(shù)研究所工作室  | 我要投稿


CPU 的工作原理是什么?

華為云開(kāi)發(fā)者聯(lián)盟

來(lái)自華為云的新鮮技術(shù)分享

前言

軟件工程師們總習(xí)慣把OS(Operating System,操作系統(tǒng))當(dāng)成是一個(gè)非常值得信賴(lài)的管家,我們只管把程序托管到OS上運(yùn)行,卻很少深入了解操作系統(tǒng)的運(yùn)行原理。確實(shí),OS作為一個(gè)通用的軟件系統(tǒng),在大多數(shù)的場(chǎng)景下都表現(xiàn)得足夠的優(yōu)秀。但仍會(huì)有一些特殊的場(chǎng)景,需要我們對(duì)OS進(jìn)行各項(xiàng)調(diào)優(yōu),才能讓業(yè)務(wù)系統(tǒng)更高效地完成任務(wù)。這就要求我們必須深入了解OS的原理,不僅僅只會(huì)使喚這個(gè)管家,還能懂得如何讓管家做得更好。

OS是一個(gè)非常龐大的軟件系統(tǒng),本文主要探索其中的冰山一角:CPU的調(diào)度原理。

說(shuō)起CPU的調(diào)度原理,很多人的第一反應(yīng)是基于時(shí)間片的調(diào)度,也即每個(gè)進(jìn)程都有占用CPU運(yùn)行的時(shí)間片,時(shí)間片用完之后,就讓出CPU給其他進(jìn)程。至于OS是如何判斷一個(gè)時(shí)間片是否用完的、如何切換到另一個(gè)進(jìn)程等等更深層的原理,了解的人似乎并不多。

其實(shí),基于時(shí)間片的調(diào)度只是眾多CPU的調(diào)度算法的一類(lèi),本文將會(huì)從最基礎(chǔ)的調(diào)度算法說(shuō)起,逐個(gè)分析各種主流調(diào)度算法的原理,帶大家一起探索CPU調(diào)度的奧秘。

CPU的上下文切換

在探索CPU調(diào)度原理之前,我們先了解一下CPU的上下文切換,它是CPU調(diào)度的基礎(chǔ)。

如今的OS幾乎都支持"同時(shí)"運(yùn)行遠(yuǎn)大于CPU數(shù)量的任務(wù),OS會(huì)將CPU輪流分配給它們使用。這就要求OS必須知道從哪里加載任務(wù),以及加載后從哪里開(kāi)始運(yùn)行,而這些信息都保存在CPU的寄存器中,其中即將執(zhí)行的下一條指令的地址被保存在程序計(jì)數(shù)器(PC)這一特殊寄存器上。我們將寄存器的這些信息稱(chēng)為CPU的上下文,也叫硬件上下文。

OS在切換運(yùn)行任務(wù)時(shí),將上一任務(wù)的上下文保存下來(lái),并將即將運(yùn)行的任務(wù)的上下文加載到CPU寄存器上的這一動(dòng)作,被稱(chēng)為CPU上下文切換。

CPU上下文屬于進(jìn)程上下文的一部分,我們常說(shuō)的進(jìn)程上下文由如下兩部分組成:

  • 用戶(hù)級(jí)上下文:包含進(jìn)程的運(yùn)行時(shí)堆棧、數(shù)據(jù)塊、代碼塊等信息。

  • 系統(tǒng)級(jí)上下文:包含進(jìn)程標(biāo)識(shí)信息、進(jìn)程現(xiàn)場(chǎng)信息

  • (CPU上下文)、進(jìn)程控制信息等信息。

這涉及到兩個(gè)問(wèn)題:(1)上一任務(wù)的CPU上下文如何保存下來(lái)?(2)什么時(shí)候執(zhí)行上下文切換?

問(wèn)題1: 上一任務(wù)的CPU上下文如何保存下來(lái)?

CPU上下文會(huì)被保存在進(jìn)程的內(nèi)核空間(kernel space)上。OS在給每個(gè)進(jìn)程分配虛擬內(nèi)存空間時(shí),會(huì)分配一個(gè)內(nèi)核空間,這部分內(nèi)存只能由內(nèi)核代碼訪問(wèn)。OS在切換CPU上下文前,會(huì)先將當(dāng)前CPU的通用寄存器、PC等進(jìn)程現(xiàn)場(chǎng)信息保存在進(jìn)程的內(nèi)核空間上,待下次切換時(shí),再取出重新裝載到CPU上,以恢復(fù)任務(wù)的運(yùn)行。

問(wèn)題2: 什么時(shí)候執(zhí)行上下文切換?

OS要想進(jìn)行任務(wù)上下文切換,必須占用CPU來(lái)執(zhí)行切換邏輯。然而,用戶(hù)程序運(yùn)行的過(guò)程中,CPU已經(jīng)被用戶(hù)程序所占用,也即OS在此刻并未處于運(yùn)行狀態(tài),自然也無(wú)法執(zhí)行上下文切換。針對(duì)該問(wèn)題,有兩種解決策略,協(xié)作式策略與搶占式策略。

協(xié)作式策略

依賴(lài)用戶(hù)程序主動(dòng)讓出CPU,比如執(zhí)行系統(tǒng)調(diào)用(System Call)或者出現(xiàn)除零等異常。但該策略并不靠譜,如果用戶(hù)程序沒(méi)有主動(dòng)讓出CPU,甚至是惡意死循環(huán),那么該程序?qū)?huì)一直占用CPU,唯一的恢復(fù)手段就是重啟系統(tǒng)了。

搶占式策略則依賴(lài)硬件的定時(shí)中斷機(jī)制(Timer Interrupt),OS會(huì)在初始化時(shí)向硬件注冊(cè)中斷處理回調(diào)(Interrupt Handler)。當(dāng)硬件產(chǎn)生中斷時(shí),硬件會(huì)將CPU的處理權(quán)交給來(lái)OS,OS就可以在中斷回調(diào)上實(shí)現(xiàn)CPU上下文的切換。

調(diào)度的衡量指標(biāo)

對(duì)于一種CPU調(diào)度算法的好壞,一般都通過(guò)如下兩個(gè)指標(biāo)來(lái)進(jìn)行衡量:

  • 周轉(zhuǎn)時(shí)間(turnaround time

  • ),指從任務(wù)到達(dá)至任務(wù)完成之間的時(shí)間,即T_{turnaround}=T_{completiong}-T_{arrival}Tturnaround=Tcompletiong?Tarrival

  • 響應(yīng)時(shí)間(response time),指從任務(wù)到達(dá)至任務(wù)首次被調(diào)度的時(shí)間,即T_{response}=T_{firstrun}-T_{arrival}Tresponse=Tfirstrun?Tarrival

兩個(gè)指標(biāo)從某種程度上是對(duì)立的,要求高的平均周轉(zhuǎn)時(shí)間,必然會(huì)降低平均響應(yīng)時(shí)間。具體追求哪種指標(biāo)與任務(wù)類(lèi)型有關(guān),比如程序編譯類(lèi)的任務(wù),要求周轉(zhuǎn)時(shí)間要小,盡可能快的完成編譯;用戶(hù)交互類(lèi)的任務(wù),則要求響應(yīng)時(shí)間要小,避免影響用戶(hù)體驗(yàn)。

工作負(fù)載假設(shè)

OS上的工作負(fù)載(也即各類(lèi)任務(wù)運(yùn)行的狀況)總是千變?nèi)f化的,為了更好的理解各類(lèi)CPU調(diào)度算法原理,我們先對(duì)工作負(fù)載進(jìn)行來(lái)如下幾種假設(shè):

  • 假設(shè)1:所有任務(wù)都運(yùn)行時(shí)長(zhǎng)都相同。

  • 假設(shè)2:所有任務(wù)的開(kāi)始時(shí)間都是相同的

  • 假設(shè)3:一旦任務(wù)開(kāi)始,就會(huì)一直運(yùn)行,直至任務(wù)完成。

  • 假設(shè)4:所有任務(wù)只使用CPU資源(比如不產(chǎn)生I/O操作)。

  • 假設(shè)5:預(yù)先知道所有任務(wù)的運(yùn)行時(shí)長(zhǎng)。

準(zhǔn)備工作已經(jīng)做好,下面我們開(kāi)始進(jìn)入CPU調(diào)度算法的奇妙世界。

FIFO:先進(jìn)先出

FIFO(First In First Out,先進(jìn)先出)調(diào)度算法以原理簡(jiǎn)單,容易實(shí)現(xiàn)著稱(chēng),它先調(diào)度首先到達(dá)的任務(wù)直至結(jié)束,然后再調(diào)度下一個(gè)任務(wù),以此類(lèi)推。如果有多個(gè)任務(wù)同時(shí)到達(dá),則隨機(jī)選一個(gè)。

在我們假設(shè)的工作負(fù)載狀況下,F(xiàn)IFO效率良好。比如有A、B、C三個(gè)任務(wù)滿足上述所有負(fù)載假設(shè),每個(gè)任務(wù)運(yùn)行時(shí)長(zhǎng)為10s,在t=0時(shí)刻到達(dá),那么任務(wù)調(diào)度情況是這樣的:

根據(jù)FIFO的調(diào)度原理,A、B、C分別在10、20、30時(shí)刻完成任務(wù),平均周轉(zhuǎn)時(shí)間為20s( \frac {10+20+30}{3}310+20+30),效果很好。

然而現(xiàn)實(shí)總是殘酷的,如果假設(shè)1被打破,比如A的運(yùn)行時(shí)間變成100s,B和C的還是10s,那么調(diào)度情況是這樣的:

根據(jù)FIFO的調(diào)度原理,由于A的運(yùn)行時(shí)間過(guò)長(zhǎng),B和C長(zhǎng)時(shí)間得不到調(diào)度,導(dǎo)致平均周轉(zhuǎn)時(shí)間惡化為110( \frac {100+110+120}{3}3100+110+120)。

因此,FIFO調(diào)度策略在任務(wù)運(yùn)行時(shí)間差異較大的場(chǎng)景下,容易出現(xiàn)任務(wù)餓死的問(wèn)題!

針對(duì)這個(gè)問(wèn)題,如果運(yùn)行時(shí)間較短的B和C先被調(diào)度,問(wèn)題就可以解決了,這正是SJF調(diào)度算法的思想。

SJF:最短任務(wù)優(yōu)先

SJF(Shortest Job First,最短任務(wù)優(yōu)先)從相同到達(dá)時(shí)間的多個(gè)任務(wù)中選取運(yùn)行時(shí)長(zhǎng)最短的一個(gè)任務(wù)進(jìn)行調(diào)度,接著再調(diào)度第二短的任務(wù),以此類(lèi)推

針對(duì)上一節(jié)的工作負(fù)載,使用SJF進(jìn)行調(diào)度的情況如下,周轉(zhuǎn)時(shí)間變成了50s( \frac {10+20+120}{3}310+20+120),相比FIFO的110s,有了2倍多的提升。

讓我們繼續(xù)打破假設(shè)2,A在t=0時(shí)刻,B和C則在t=10時(shí)刻到達(dá),那么調(diào)度情況會(huì)變成這樣:

因?yàn)槿蝿?wù)B和C比A后到,它們不得不一直等待A運(yùn)行結(jié)束后才有機(jī)會(huì)調(diào)度,即使A需要長(zhǎng)時(shí)間運(yùn)行。周轉(zhuǎn)時(shí)間惡化為103.33s(\frac {100+(110-10)+(120-10)}{3}3100+(110?10)+(120?10)),再次出現(xiàn)任務(wù)餓死的問(wèn)題!

STCF:最短時(shí)間完成優(yōu)先

為了解決SJF的任務(wù)餓死問(wèn)題,我們需要打破假設(shè)3,也即任務(wù)在運(yùn)行過(guò)程中是允許被打斷的。如果B和C在到達(dá)時(shí)就立即被調(diào)度,問(wèn)題就解決了。這屬于搶占式調(diào)度,原理就是CPU上下文切換一節(jié)提到的,在中斷定時(shí)器到達(dá)之后,OS完成任務(wù)A和B的上下文切換。

我們?cè)趨f(xié)作式調(diào)度的SJF算法的基礎(chǔ)上,加上搶占式調(diào)度算法,就演變成了STCF算法(Shortest Time-to-Completion First,最短時(shí)間完成優(yōu)先),調(diào)度原理是當(dāng)運(yùn)行時(shí)長(zhǎng)較短的任務(wù)到達(dá)時(shí),中斷當(dāng)前的任務(wù),優(yōu)先調(diào)度運(yùn)行時(shí)長(zhǎng)較短的任務(wù)。

使用STCF算法對(duì)該工作負(fù)載進(jìn)行調(diào)度的情況如下,周轉(zhuǎn)時(shí)間優(yōu)化為50s(\frac {120+(20-10)+(30-10)}{3}3120+(20?10)+(30?10)),再次解決了任務(wù)餓死問(wèn)題!

到目前為止,我們只關(guān)心了周轉(zhuǎn)時(shí)間這一衡量指標(biāo),那么FIFO、SJF和STCF調(diào)度算法的響應(yīng)時(shí)間又是多長(zhǎng)呢?

不妨假設(shè)A、B、C三個(gè)任務(wù)都在t=0時(shí)刻到達(dá),運(yùn)行時(shí)長(zhǎng)都是5s,那么這三個(gè)算法的調(diào)度情況如下,平均響應(yīng)時(shí)長(zhǎng)

為5s(\frac {0+(5-0)+(10-0)}{3}30+(5?0)+(10?0)):

更糟糕的是,隨著任務(wù)運(yùn)行時(shí)長(zhǎng)的增長(zhǎng),平均響應(yīng)時(shí)長(zhǎng)也隨之增長(zhǎng),這對(duì)于交互類(lèi)任務(wù)來(lái)說(shuō)將會(huì)是災(zāi)難性的,嚴(yán)重影響用戶(hù)體驗(yàn)。該問(wèn)題的根源在于,當(dāng)任務(wù)都同時(shí)到達(dá)且運(yùn)行時(shí)長(zhǎng)相同時(shí),最后一個(gè)任務(wù)必須等待其他任務(wù)全部完成之后才開(kāi)始調(diào)度。

為了優(yōu)化響應(yīng)時(shí)間,我們熟悉的基于時(shí)間片的調(diào)度出現(xiàn)了。

RR:基于時(shí)間片的輪詢(xún)調(diào)度

RR(Round Robin,輪訓(xùn))算法給每個(gè)任務(wù)分配一個(gè)時(shí)間片,當(dāng)任務(wù)的時(shí)間片用完之后,調(diào)度器會(huì)中斷當(dāng)前任務(wù),切換到下一個(gè)任務(wù),以此類(lèi)推。

需要注意的是,時(shí)間片的長(zhǎng)度設(shè)置必須是中斷定時(shí)器

的整數(shù)倍,比如中斷定時(shí)器時(shí)長(zhǎng)為2ms,那么任務(wù)的時(shí)間片可以設(shè)置為2ms、4ms、6ms … 否則即使任務(wù)的時(shí)間片用完之后,定時(shí)中斷沒(méi)發(fā)生,OS也無(wú)法切換任務(wù)。

現(xiàn)在,使用RR進(jìn)行調(diào)度,給A、B、C分配一個(gè)1s的時(shí)間片,那么調(diào)度情況如下,平均響應(yīng)時(shí)長(zhǎng)為1s(\frac {0+(1-0)+(2-0)}{3}30+(1?0)+(2?0)):

從RR的調(diào)度原理可以發(fā)現(xiàn),把時(shí)間片設(shè)置得越小,平均響應(yīng)時(shí)間也越小。但隨著時(shí)間片的變小,任務(wù)切換的次數(shù)也隨之上升,也就是上下文切換的消耗會(huì)變大。因此,時(shí)間片大小的設(shè)置是一個(gè)trade-off的過(guò)程,不能一味追求響應(yīng)時(shí)間而忽略CPU上下文切換帶來(lái)的消耗。

CPU上下文切換的消耗,不只是保存和恢復(fù)寄存器所帶來(lái)的消耗。程序在運(yùn)行過(guò)程中,會(huì)逐漸在CPU各級(jí)緩存、TLB、分支預(yù)測(cè)器等硬件上建立屬于自己的緩存數(shù)據(jù)。當(dāng)任務(wù)被切換后,就意味著又得重來(lái)一遍緩存預(yù)熱,這會(huì)帶來(lái)巨大的消耗。

另外,RR調(diào)度算法的周轉(zhuǎn)時(shí)間為14s(\frac {(13-0)+(14-0)+(15-0)}{3}3(13?0)+(14?0)+(15?0)),相比于FIFO、SJF和STCF的10s(\frac {(5-0)+(10-0)+(15-0)}{3}3(5?0)+(10?0)+(15?0))差了不少。這也驗(yàn)證了之前所說(shuō)的,周轉(zhuǎn)時(shí)間和響應(yīng)時(shí)間在某種程度上是對(duì)立的,如果想要優(yōu)化周轉(zhuǎn)時(shí)間,建議使用SJF和STCF;如果想要優(yōu)化響應(yīng)時(shí)間,則建議使用RR。

I/O操作對(duì)調(diào)度的影響

到目前為止,我們并未考慮任何的I/O操作。我們知道,當(dāng)觸發(fā)I/O操作時(shí),進(jìn)程并不會(huì)占用CPU,而是阻塞等待I/O操作的完成?,F(xiàn)在讓我們打破假設(shè)4,考慮任務(wù)A和B都在t=0時(shí)刻到達(dá),運(yùn)行時(shí)長(zhǎng)都是50ms,但A每隔10ms執(zhí)行一次阻塞10ms的I/O操作,而B(niǎo)沒(méi)有I/O。

如果使用STCF進(jìn)行調(diào)度,調(diào)度的情況是這樣的:

從上圖看出,任務(wù)A和B的調(diào)度總時(shí)長(zhǎng)達(dá)到了140ms,比實(shí)際A和B運(yùn)行時(shí)長(zhǎng)總和100ms要大。而且A阻塞在I/O操作期間,調(diào)度器并沒(méi)有切換到B,導(dǎo)致了CPU的空轉(zhuǎn)!

要解決該問(wèn)題,只需使用RR的調(diào)度算法,給任務(wù)A和B分配10ms的時(shí)間片,這樣當(dāng)A阻塞在I/O操作時(shí),就可以調(diào)度B,而B(niǎo)用完時(shí)間片后,恰好A也從I/O阻塞中返回,以此類(lèi)推,調(diào)度總時(shí)長(zhǎng)優(yōu)化至100ms。

該調(diào)度方案是建立在假設(shè)5之上的,也即要求調(diào)度器預(yù)先知道A和B的運(yùn)行時(shí)長(zhǎng)、I/O操作時(shí)間長(zhǎng)等信息,才能如此充分地利用CPU。然而,實(shí)際的情況遠(yuǎn)比這復(fù)雜,I/O阻塞時(shí)長(zhǎng)不會(huì)每次都一樣,調(diào)度器也無(wú)法準(zhǔn)確知道A和B的運(yùn)行信息。當(dāng)假設(shè)5也被打破時(shí),調(diào)度器又該如何實(shí)現(xiàn)才能最大程度保證CPU利用率,以及調(diào)度的合理性呢?

接下來(lái),我們將介紹一個(gè)能夠在所有工作負(fù)載假設(shè)被打破的情況下依然表現(xiàn)良好,被許多現(xiàn)代操作系統(tǒng)采用的CPU調(diào)度算法,MLFQ。

MLFQ:多級(jí)反饋隊(duì)列

MLFQ(Multi-Level Feedback Queue,多級(jí)反饋隊(duì)列)調(diào)度算法的目標(biāo)如下:

  1. 優(yōu)化周轉(zhuǎn)時(shí)間。

  2. 降低交互類(lèi)任務(wù)的響應(yīng)時(shí)間,提升用戶(hù)體驗(yàn)。

從前面分析我們知道,要優(yōu)化周轉(zhuǎn)時(shí)間,可以?xún)?yōu)先調(diào)度運(yùn)行時(shí)長(zhǎng)短的任務(wù)(像SJF和STCF的做法);要優(yōu)化響應(yīng)時(shí)間,則采用類(lèi)似RR的基于時(shí)間片的調(diào)度。然而,這兩個(gè)目標(biāo)看起來(lái)是矛盾的,要降低響應(yīng)時(shí)間,必然會(huì)增加周轉(zhuǎn)時(shí)間。

那么對(duì)MLFQ來(lái)說(shuō),就需要解決如下兩個(gè)問(wèn)題:

  1. 在不預(yù)先清楚任務(wù)的運(yùn)行信息(包括運(yùn)行時(shí)長(zhǎng)、I/O操作等)的前提下,如何權(quán)衡周轉(zhuǎn)時(shí)間和響應(yīng)時(shí)間?

  2. 如何從歷史調(diào)度中學(xué)習(xí),以便未來(lái)做出更好的決策?

劃分任務(wù)的優(yōu)先級(jí)

MLFQ與前文介紹的幾種調(diào)度算法最顯著的特點(diǎn)就是新增了優(yōu)先級(jí)隊(duì)列存放不同優(yōu)先級(jí)的任務(wù),并定下了如下兩個(gè)規(guī)則:

  • 規(guī)則1:如果Priority(A) > Priority(B),則調(diào)度A

  • 規(guī)則2:如果Priority(A) = Priority(B),則按照RR算法調(diào)度A和B

優(yōu)先級(jí)的變化

MLFQ必須考慮改變?nèi)蝿?wù)的優(yōu)先級(jí),否則根據(jù) 規(guī)則1規(guī)則2 ,對(duì)于上圖中的任務(wù)C,在A和B運(yùn)行結(jié)束之前,C都不會(huì)獲得運(yùn)行的機(jī)會(huì),導(dǎo)致C的響應(yīng)時(shí)間很長(zhǎng)。因此,可以定下了如下幾個(gè)優(yōu)先級(jí)變化規(guī)則:

  • 規(guī)則3:當(dāng)一個(gè)新的任務(wù)到達(dá)時(shí),將它放到最高優(yōu)先級(jí)隊(duì)列

  • 規(guī)則4a:如果任務(wù)A運(yùn)行了一個(gè)時(shí)間片都沒(méi)有主動(dòng)讓出CPU(比如I/O操作),則優(yōu)先級(jí)降低一級(jí)

  • 規(guī)則4b:如果任務(wù)A在時(shí)間片用完之前,有主動(dòng)讓出CPU,則優(yōu)先級(jí)保持不變

規(guī)則3主要考慮到讓新加入的任務(wù)都能得到調(diào)度機(jī)會(huì),避免出現(xiàn)任務(wù)餓死的問(wèn)題

規(guī)則4a和4b主要考慮到,交互類(lèi)任務(wù)大都是short-running的,并且會(huì)頻繁讓出CPU,因此為了保證響應(yīng)時(shí)間,需要保持現(xiàn)有的優(yōu)先級(jí);而CPU密集型任務(wù),往往不會(huì)太關(guān)注響應(yīng)時(shí)間,因此可以降低優(yōu)先級(jí)。

按照上述規(guī)則,當(dāng)一個(gè)long-running任務(wù)A到達(dá)時(shí),調(diào)度情況是這樣的:

如果在任務(wù)A運(yùn)行到t=100時(shí),short-time任務(wù)B到達(dá),調(diào)度情況是這樣的:

從上述調(diào)度情況可以看出,MLFQ具備了STCF的優(yōu)點(diǎn),即可以?xún)?yōu)先完成short-running任務(wù)的調(diào)度,縮短了周轉(zhuǎn)時(shí)間。

如果任務(wù)A運(yùn)行到t=100時(shí),交互類(lèi)任務(wù)C到達(dá),那么調(diào)度情況是這樣的:

MLFQ會(huì)在任務(wù)處于阻塞時(shí)按照優(yōu)先級(jí)選擇其他任務(wù)運(yùn)行,避免CPU空轉(zhuǎn)。因此,在上圖中,當(dāng)任務(wù)C處于I/O阻塞狀態(tài)時(shí),任務(wù)A得到了運(yùn)行時(shí)間片,當(dāng)任務(wù)C從I/O阻塞上返回時(shí),A再次掛起,以此類(lèi)推。另外,因?yàn)槿蝿?wù)C在時(shí)間片之內(nèi)出現(xiàn)主動(dòng)讓出CPU的行為,C的優(yōu)先級(jí)一直保持不變,這對(duì)于交互類(lèi)任務(wù)而言,有效提升了用戶(hù)體驗(yàn)。

CPU密集型任務(wù)餓死問(wèn)題

到目前為止,MLFQ似乎能夠同時(shí)兼顧周轉(zhuǎn)時(shí)間,以及交互類(lèi)任務(wù)的響應(yīng)時(shí)間,它真的完美了嗎?

考慮如下場(chǎng)景,任務(wù)A運(yùn)行到t=100時(shí),交互類(lèi)任務(wù)C和D同時(shí)到達(dá),那么調(diào)度情況會(huì)是這樣的:

由此可見(jiàn),如果當(dāng)前系統(tǒng)上存在很多交互類(lèi)任務(wù)時(shí),CPU密集型任務(wù)將會(huì)存在餓死的可能!

為了解決該問(wèn)題,可以設(shè)立了如下規(guī)則:

  • 規(guī)則5:系統(tǒng)運(yùn)行S時(shí)長(zhǎng)之后,將所有任務(wù)放到最高優(yōu)先級(jí)隊(duì)列上(Priority Boost

加上該規(guī)則之后,假設(shè)設(shè)置S為50ms,那么調(diào)度情況是這樣的,餓死問(wèn)題得到解決!

惡意任務(wù)問(wèn)題

考慮如下一個(gè)惡意任務(wù)E,為了長(zhǎng)時(shí)間占用CPU,任務(wù)E在時(shí)間片還剩1%時(shí)故意執(zhí)行I/O操作,并很快返回。根據(jù)規(guī)則4b,E將會(huì)維持在原來(lái)的最高優(yōu)先級(jí)隊(duì)列上,因此下次調(diào)度時(shí)仍然獲得調(diào)度優(yōu)先權(quán):

為了解決該問(wèn)題,我們需要將規(guī)則4調(diào)整為如下規(guī)則:

  • 規(guī)則4:給每個(gè)優(yōu)先級(jí)分配一個(gè)時(shí)間片,當(dāng)任務(wù)用完該優(yōu)先級(jí)的時(shí)間片后,優(yōu)先級(jí)降一級(jí)

應(yīng)用新的規(guī)則4后,相同的工作負(fù)載,調(diào)度情況變成了如下所述,不再出現(xiàn)惡意任務(wù)E占用大量CPU的問(wèn)題。

到目前為止,MLFQ的基本原理已經(jīng)介紹完,最后,我們總結(jié)下MLFQ最關(guān)鍵的5項(xiàng)規(guī)則:

  • 規(guī)則1:如果Priority(A) > Priority(B),則調(diào)度A

  • 規(guī)則2:如果Priority(A) = Priority(B),則按照RR算法調(diào)度A和B

  • 規(guī)則3:當(dāng)一個(gè)新的任務(wù)到達(dá)時(shí),將它放到最高優(yōu)先級(jí)隊(duì)列中

  • 規(guī)則4:給每個(gè)優(yōu)先級(jí)分配一個(gè)時(shí)間片,當(dāng)任務(wù)用完該優(yōu)先級(jí)的時(shí)間片后,優(yōu)先級(jí)降一級(jí)

  • 規(guī)則5:系統(tǒng)運(yùn)行S時(shí)長(zhǎng)之后,將所有任務(wù)放到最高優(yōu)先級(jí)隊(duì)列上(Priority Boost

現(xiàn)在,再回到本節(jié)開(kāi)始時(shí)提出的兩個(gè)問(wèn)題:

1、在不預(yù)先清楚任務(wù)的運(yùn)行信息(包括運(yùn)行時(shí)長(zhǎng)、I/O操作等)的前提下,MLFQ如何權(quán)衡周轉(zhuǎn)時(shí)間和響應(yīng)時(shí)間

在預(yù)先不清楚任務(wù)到底是long-running或short-running的情況下,MLFQ會(huì)先假設(shè)任務(wù)屬于shrot-running

任務(wù),如果假設(shè)正確,任務(wù)就會(huì)很快完成,周轉(zhuǎn)時(shí)間和響應(yīng)時(shí)間都得到優(yōu)化;即使假設(shè)錯(cuò)誤,任務(wù)的優(yōu)先級(jí)也能逐漸降低,把更多的調(diào)度機(jī)會(huì)讓給其他short-running任務(wù)。

2、MLFQ如何從歷史調(diào)度中學(xué)習(xí),以便未來(lái)做出更好的決策?

MLFQ主要根據(jù)任務(wù)是否有主動(dòng)讓出CPU的行為來(lái)判斷其是否是交互類(lèi)任務(wù)

,如果是,則維持在當(dāng)前的優(yōu)先級(jí),保證該任務(wù)的調(diào)度優(yōu)先權(quán),提升交互類(lèi)任務(wù)的響應(yīng)性。

當(dāng)然,MLFQ并非完美的調(diào)度算法,它也存在著各種問(wèn)題,其中最讓人困擾的就是MLFQ各項(xiàng)參數(shù)的設(shè)定,比如優(yōu)先級(jí)隊(duì)列的數(shù)量,時(shí)間片的長(zhǎng)度、Priority Boost的間隔等。這些參數(shù)并沒(méi)有完美的參考值,只能根據(jù)不同的工作負(fù)載來(lái)進(jìn)行設(shè)置。

比如,我們可以將低優(yōu)先級(jí)隊(duì)列上任務(wù)的時(shí)間片設(shè)置長(zhǎng)一些,因?yàn)榈蛢?yōu)先級(jí)的任務(wù)往往是CPU密集型任務(wù),它們不太關(guān)心響應(yīng)時(shí)間,較長(zhǎng)的時(shí)間片長(zhǎng)能夠減少上下文切換帶來(lái)的消耗。

CFS:Linux的完全公平調(diào)度

本節(jié)我們將介紹一個(gè)平時(shí)打交道最多的調(diào)度算法,Linux系統(tǒng)下的CFS(Completely Fair Scheduler,完全公平調(diào)度)。與上一節(jié)介紹的MLFQ不同,CFS并非以?xún)?yōu)化周轉(zhuǎn)時(shí)間和響應(yīng)時(shí)間為目標(biāo),而是希望將CPU公平地均分給每個(gè)任務(wù)。

當(dāng)然,CFS也提供了給進(jìn)程設(shè)置優(yōu)先級(jí)的功能,讓用戶(hù)/管理員決定哪些進(jìn)程需要獲得更多的調(diào)度時(shí)間。

基本原理

大部分調(diào)度算法都是基于固定時(shí)間片來(lái)進(jìn)行調(diào)度,而CFS另辟蹊徑,采用基于計(jì)數(shù)的調(diào)度方法,該技術(shù)被稱(chēng)為virtual runtime。

CFS給每個(gè)任務(wù)都維護(hù)一個(gè)vruntime值

,每當(dāng)任務(wù)被調(diào)度之后,就累加它的vruntime。比如,當(dāng)任務(wù)A運(yùn)行了5ms的時(shí)間片之后,則更新為vruntime += 5ms。CFS在下次調(diào)度時(shí),選擇vruntime值最小的任務(wù)來(lái)調(diào)度,比如:

那CFS應(yīng)該什么時(shí)候進(jìn)行任務(wù)切換呢?切換得頻繁些,任務(wù)的調(diào)度會(huì)更加的公平,但是上下文切換帶來(lái)的消耗也越大。因此,CFS給用戶(hù)提供了個(gè)可配參數(shù)sched_latency,讓用戶(hù)來(lái)決定切換的時(shí)機(jī)。CFS將每個(gè)任務(wù)分到的時(shí)間片設(shè)置為 time_slice = sched_latency / n(n為當(dāng)前的任務(wù)數(shù)) ,以確保在sched_latency周期內(nèi),各任務(wù)能夠均分CPU,保證公平性。

比如將sched_latency設(shè)置為48ms,當(dāng)前有4個(gè)任務(wù)A、B、C和D,那么每個(gè)任務(wù)分到的時(shí)間片為12ms;后面C和D結(jié)束之后,A和B分到的時(shí)間片也更新為24ms:

從上述原理上看,在sched_latency 不變的情況下,隨著系統(tǒng)任務(wù)數(shù)的增加,每個(gè)任務(wù)分到的時(shí)間片也隨之減少,任務(wù)切換所帶來(lái)的消耗也會(huì)增大。為了避免過(guò)多的任務(wù)切換消耗,CFS提供了可配參數(shù)min_granularity來(lái)設(shè)置任務(wù)的最小時(shí)間片。比如sched_latency設(shè)置為48ms,min_granularity設(shè)置為 6ms,那么即使當(dāng)前任務(wù)數(shù)有12,每個(gè)任務(wù)數(shù)分到的時(shí)間片也是6ms,而不是4ms。

給任務(wù)分配權(quán)重

有時(shí)候,我們希望給系統(tǒng)中某個(gè)重要的業(yè)務(wù)進(jìn)程多分配些時(shí)間片,而其他不重要的進(jìn)程則少分配些時(shí)間片。但按照上一節(jié)介紹的基本原理,使用CFS調(diào)度時(shí),每個(gè)任務(wù)都是均分CPU的,有沒(méi)有辦法可以做到這一點(diǎn)呢?

可以給任務(wù)分配權(quán)重,讓權(quán)重高的任務(wù)更多的CPU!

加上權(quán)重機(jī)制后,任務(wù)時(shí)間片的計(jì)算方式變成了這樣:

比如,sched_latency還是設(shè)置為48ms,現(xiàn)有A和B兩個(gè)任務(wù),A的權(quán)重設(shè)置為1024,B的權(quán)重設(shè)置為3072,按照上述的公式,A的時(shí)間片是12ms,B的時(shí)間片是36ms。

從上一節(jié)可知,CFS每次選取vruntime值最小的任務(wù)來(lái)調(diào)度,而每次調(diào)度完成后,vruntime的計(jì)算規(guī)則為vruntime += runtime,因此僅僅改變時(shí)間片的計(jì)算規(guī)則不會(huì)生效,還需將vruntime的計(jì)算規(guī)則調(diào)整為:

還是前面的例子,假設(shè)A和B都沒(méi)有I/O操作,更新vruntime計(jì)算規(guī)則后,調(diào)度情況如下,任務(wù)B比任務(wù)A能夠分得更多的CPU了。

使用紅黑樹(shù)提升vruntime查找效率

CFS每次切換任務(wù)時(shí),都會(huì)選取vruntime值最小的任務(wù)來(lái)調(diào)度,因此需要它有個(gè)數(shù)據(jù)結(jié)構(gòu)來(lái)存儲(chǔ)各個(gè)任務(wù)及其vruntime信息。

最直觀的當(dāng)然就是選取一個(gè)有序列表來(lái)存儲(chǔ)這些信息,列表按照vruntime排序。這樣在切換任務(wù)時(shí),CFS只需獲取列表頭的任務(wù)即可,時(shí)間復(fù)雜度為O(1)。比如當(dāng)前有10個(gè)任務(wù),vruntime保存為有序鏈表[1, 5, 9, 10, 14, 18, 17, 21, 22, 24],但是每次插入或刪除任務(wù)時(shí),時(shí)間復(fù)雜度會(huì)是O(N),而且耗時(shí)隨著任務(wù)數(shù)的增多而線性增長(zhǎng)!

為了兼顧查詢(xún)、插入、刪除的效率,CFS使用紅黑樹(shù)來(lái)保存任務(wù)和vruntime信息,這樣,查詢(xún)、插入、刪除操作的復(fù)雜度變成了log(N),并不會(huì)隨著任務(wù)數(shù)的增多而線性增長(zhǎng),極大提升了效率。

另外,為了提升存儲(chǔ)效率,CFS在紅黑樹(shù)中只保存了處于Running狀態(tài)的任務(wù)的信息。

應(yīng)對(duì)I/O與休眠

每次都選取vruntime值最小的任務(wù)來(lái)調(diào)度這種策略,也會(huì)存在任務(wù)餓死的問(wèn)題。考慮有A和B兩個(gè)任務(wù),時(shí)間片為1s,起初A和B均分CPU輪流運(yùn)行,在某次調(diào)度后,B進(jìn)入了休眠,假設(shè)休眠了10s。等B醒來(lái)后,vruntime_{B}vruntimeB就會(huì)比vruntime_{A}vruntimeA小10s,在接下來(lái)的10s中,B將會(huì)一直被調(diào)度,從而任務(wù)A出現(xiàn)了餓死現(xiàn)象。

為了解決該問(wèn)題,CFS規(guī)定當(dāng)任務(wù)從休眠或I/O中返回時(shí),該任務(wù)的vruntime會(huì)被設(shè)置為當(dāng)前紅黑樹(shù)中的最小vruntime值。上述例子,B從休眠中醒來(lái)后,vruntime_{B}vruntimeB會(huì)被設(shè)置為11,因此也就不會(huì)餓死任務(wù)A了。

這種做法其實(shí)也存在瑕疵,如果任務(wù)的休眠時(shí)間很短,那么它醒來(lái)后依舊是優(yōu)先調(diào)度,這對(duì)于其他任務(wù)來(lái)說(shuō)是不公平的。

寫(xiě)在最后

本文花了很長(zhǎng)的篇幅講解了幾種常見(jiàn)CPU調(diào)度算法的原理,每種算法都有各自的優(yōu)缺點(diǎn),并不存在一種完美的調(diào)度策略。在應(yīng)用中,我們需要根據(jù)實(shí)際的工作負(fù)載,選取合適的調(diào)度算法,配置合理的調(diào)度參數(shù),權(quán)衡周轉(zhuǎn)時(shí)間和響應(yīng)時(shí)間、任務(wù)公平和切換消耗。這些都應(yīng)驗(yàn)了《Fundamentals of Software Architecture》中的那句名言:Everything in software architecture is a trade-off.

本文中描述的調(diào)度算法都是基于單核處理器進(jìn)行分析的,而多核處理器上的調(diào)度算法要比這復(fù)雜很多,比如需要考慮處理器之間共享數(shù)據(jù)同步、緩存親和性等,但本質(zhì)原理依然離不開(kāi)本文所描述的幾種基礎(chǔ)調(diào)度算法。

參考

  1. Operating Systems: Three Easy Pieces, Remzi H Arpaci-Dusseau / Andrea C Arpaci-Dusseau

  2. 計(jì)算機(jī)系統(tǒng)基礎(chǔ)(三):異常、中斷和輸入/輸出, 袁春風(fēng)

  1. 南京大學(xué)

以上內(nèi)容分享自華為云社區(qū)《探索CPU的調(diào)度原理》,作者:元閏子。



【知乎】CPU 的工作原理是什么?的評(píng)論 (共 條)

分享到微博請(qǐng)遵守國(guó)家法律
尤溪县| 洪洞县| 恭城| 博白县| 治多县| 庄河市| 望江县| 汪清县| 桃源县| 栾城县| 靖远县| 咸阳市| 大关县| 中阳县| 新疆| 彭水| 板桥市| 和硕县| 西丰县| 镇坪县| 湘西| 土默特右旗| 霍林郭勒市| 大竹县| 孟州市| 建始县| 潼南县| 龙岩市| 华池县| 肃宁县| 丘北县| 阿克苏市| 临澧县| 玉门市| 巢湖市| 洛浦县| 正阳县| 望城县| 青岛市| 木里| 井研县|