樸素的UNIX之-Linux CFS一個注釋

發(fā)布時間：2020-05-29 08:33:29

來源：51CTO

閱讀：604

作者：dog250

本系列名為樸素的UNIX，但是也包括各個類UNIX系統(tǒng)的細(xì)節(jié)，本系列文章整理自本人幾年來的學(xué)習(xí)筆記，著重分析各個UNIX，類UNIX的實(shí)現(xiàn)思想以及感悟。

本文比較短，只是分析一下Linux CFS調(diào)度器的一個細(xì)節(jié)。

在進(jìn)程尋找下一個將被運(yùn)行的進(jìn)程時，難道僅僅只是在紅黑樹上取下左下角的進(jìn)程嗎？事實(shí)上最樸素的實(shí)現(xiàn)就是這樣，但是考慮到優(yōu)化的話，就沒有這么簡單了。要

考慮CPU緩存的利用率，即如果一個進(jìn)程A搶占了進(jìn)程B，那么在A進(jìn)程的上下文中，pick

next是選擇進(jìn)程B呢還是選擇紅黑樹的左下角進(jìn)程呢？另外如果進(jìn)程A剛被喚醒，企圖搶占進(jìn)程B，但是沒有成功，那么下一個是選擇紅黑樹的左下角進(jìn)程呢還

是選擇進(jìn)程A呢？是的，這些都是問題。

我們看一下pick next的實(shí)現(xiàn)：static?struct?sched_entity?*pick_next_entity(struct?cfs_rq?*cfs_rq)

{

struct?sched_entity?*se?=?__pick_next_entity(cfs_rq);

struct?sched_entity?*left?=?se;

if?(cfs_rq->next?&&?wakeup_preempt_entity(cfs_rq->next,?left)?

se?=?cfs_rq->next;

/*

*?Prefer?last?buddy,?try?to?return?the?CPU?to?a?preempted?task.

*/

if?(cfs_rq->last?&&?wakeup_preempt_entity(cfs_rq->last,?left)?

se?=?cfs_rq->last;

clear_buddies(cfs_rq,?se);

return?se;

}

很顯然，要把紅黑樹最左下角的進(jìn)程和另外兩個進(jìn)程，即next和last最比較，next是搶占失敗的進(jìn)程，而last則是搶占成功后被搶占的進(jìn)程，這三個進(jìn)程到底哪一個是最優(yōu)的next進(jìn)程呢？Linux CFS實(shí)現(xiàn)的判決條件是：

1.盡可能滿足需要剛被喚醒的進(jìn)程搶占其它進(jìn)程的需求；

2.盡可能減少以上這種搶占帶來的緩存刷新的影響。

Linux CFS實(shí)現(xiàn)是怎么做到的呢？Linux保存了兩個變量，即搶占失敗的進(jìn)程和搶占成功后被搶占的進(jìn)程，在權(quán)衡的時候，優(yōu)先選擇的順序是：

搶占成功后被搶占的進(jìn)程>搶占失敗的進(jìn)程>紅黑樹最左下角的進(jìn)程

到底能不能選擇前兩個進(jìn)程，則是wakeup_preempt_entity函數(shù)來決定的，代碼太多無益，看下面的圖解即可：

這個CFS的細(xì)節(jié)在Linux 2.6.23最初實(shí)現(xiàn)CFS時并沒有實(shí)現(xiàn)。因此從最樸素的時×××始，你才能逐漸理解細(xì)節(jié)的來龍去脈，看Changelog是有好處的。不得不說，讀史使人明智。

總結(jié)

以上是生活随笔為你收集整理的linux cfs,朴素的UNIX之-Linux CFS一个注释的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。