內核調度模型

今天偶然談起了進程的相關概念，發現其中有許多不清晰的地方，現就以上的概念作一些研究，所參考的資料所有來自於網絡，因此對於其中不正確的地方，歡迎你們給我指正，讓我可以對以上概念更加清晰。

好，首先理清以上幾個概念，先來看「內核線程」。此處要申明的一點是，從我所看到的資料來看（《Linux內核設計與實現》、《深刻理解Linux內核》以及網上的諸多文章），只有「內核線程」的概念，不存在所謂的「內核進程」。此處對於內核線程的具體定義我並無找到，不過能夠從它的功能出發，窺探一二。

關於內核線程的做用主要參考自如下文章：http://blog.csdn.net/kickxxx/article/details/9211381

內核線程的做用主要有：

 週期性的將dirty內存頁同步到磁盤設備上。 好比 bpflush線程週期性的把dirty數據寫回磁盤
 內存頁不多的狀況下，把內存page 交換到磁盤空間。 好比kswapd，系統會爲每個NUMA建立一個kswapd進程，可是在非NUMA系統上，則僅有一個kswapd
 管理延時動做
 實現文件系統的事物日誌
主要包括兩種類型的內核線程：

線程按週期性間隔運行，檢測特定資源的使用，在用量超出或者低於預置的限制時採起行動
在線程啓動後則一直等待，直到內核線程請求執行某一特定的操做。
同時內核線程是由內核本身建立的線程，也叫作守護線程(deamon)。在終端上用命令」ps -Al」列出的全部進程中，名字以k開關以d結尾的每每都是內核線程，好比kthreadd、kswapd。

既然是內核線程是一個單獨的概念，那麼與用戶線程之間必定存在某些區別，主要區別參考自如下文章：http://www.2ndmoon.net/weblog/?p=603

內核線程與用戶線程的相同點是：

都由do_fork()建立，每一個線程都有獨立的task_struct和內核棧；
都參與調度，內核線程也有優先級，會被調度器平等地換入換出
不一樣之處在於：

內核線程只工做在內核態中；而用戶線程則既能夠運行在內核態（執行系統調用時），也能夠運行在用戶態；
內核線程沒有用戶空間，因此對於一個內核線程來講，它的0~3G的內存空間是空白的，它的current->mm是空的，與內核使用同一張頁表；而用戶線程則能夠看到完整的0~4G內存空間。
在Linux內核啓動的最後階段，系統會建立兩個內核線程，一個是init，一個是kthreadd。其中init線程的做用是運行文件系統上的一系列」init」腳本，並啓動shell進程，因此init線程稱得上是系統中全部用戶進程的祖先，它的pid是1。kthreadd線程是內核的守護線程，在內核正常工做時，它永遠不退出，是一個死循環，它的pid是2。

經過上述不一樣之處的對比能夠發現，內核線程沒有用戶內存空間，與之相對的是用戶進程（注意，此處不是用戶線程，用戶線程內存空間與用戶進程空間之間存在的必定差別，具體差別能夠參考我以前的博文），用戶進程同時具有內核空間與用戶空間，在進行系統調用時用戶進程會由用戶內存空間陷入內核內存空間。之因此此處採用內核線程與用戶進程（而非用戶線程）進行對比，是因爲內核線程（kernel thread）是「獨立運行在內核空間的標準進程」（以上這句話摘自《linux內核設計與實現》），所以從功能上看內核線程一方面具備進程的概念特色——具備獨立功能的程序關於某個數據集合上的一次執行活動，是系統進行資源分配的單位，同時內核線程又具備線程的概念特色——進程內的一個可調度實體。

好了經過以上分析基本能夠分清「內核線程（kernel thread）」、「用戶進程」、「用戶線程」這幾個基本概念。這裏要補充的一點是以上幾個概念所有是在邏輯層面上的，從實現的角度來看linux內核自己並不支持線程這一律念，linux 將全部的線程都看成進程來實現。內核並無準備特別的調度算法或是定義特別的數據結構來表徵線程。相反，線程僅僅被視爲一個與其餘進程（概念上應該是線程）共享某些資源的進程（概念上應該是線程）。每一個線程都擁有惟一隸屬於本身的task_struct，因此在內核中，它看起來就像是一個普通的進程（只是線程和其餘一些進程共享某些資源，如地址空間）。關於這一點能夠經過系統調用clone的實現來驗證，不管是fork、vfork、kthread_create最後都是要調用do_fork，而do_fork就是根據不一樣的函數參數，對一個進程所需的資源進行分配。在linux2.6以前，內核並不支持線程的概念，僅經過輕量級進程（lightweight process）模擬線程，一個用戶線程對應一個內核線程（內核輕量級進程），這種模型最大的特色是線程調度由內核完成了，而其餘線程操做（同步、取消）等都是核外的線程庫（LinuxThread）函數完成的。但這個問題還存在不少的問題，具體問題請見http://www.ibm.com/developerworks/cn/linux/kernel/l-thread/index.html 這篇文章中的第6小節。在linux2.6以後，爲了徹底兼容posix標準，linux2.6首先對內核進行了改進，引入了線程組的概念（仍然用輕量級進程表示線程），有了這個概念就能夠將一組線程組織稱爲一個進程，如此經過這個改變，linux內核正式支持多線程特性。以上是邏輯上的改變，在實現上主要的改變就是在task_struct中加入tgid字段，這個字段就是用於表示線程組id的字段。在用戶線程庫方面，也使用NPTL代替LinuxThread。不一樣調度模型上仍然採用「1對1」模型，關於線程的調度模型，接下來會詳細分析。

對於linux內核中對於多線程支持的變化歷史請見如下這篇blog：http://blog.sina.com.cn/s/blog_631d3a630102uwn2.html

關於LinuxThread與NPTL的對比請見這篇文章：http://blog.csdn.net/ixidof/article/details/24579879

對於2.4內核中線程的實現，請見這篇文章http://www.ibm.com/developerworks/cn/linux/kernel/l-thread/index.html

接下來來看看內核線程與用戶線程之間的對應關係。首先從原理上出發，對內核線程與用戶線程之間的對應關係進行分析。

如今在支持多線程的操做系統中通常採用三種調度模型，分別是「一對一模型」、「多對一模型」、「多對多模型」。

以上內容參考自下述兩篇blog

http://www.cnblogs.com/zhaoyl/p/3620204.html

1）「一對一模型」

一對一模型中，每一個用戶線程都對應各自的內核調度實體。內核會對每一個線程進行調度，能夠調度到其餘處理器上面。固然由內核來調度的結果就是：線程的每次操做會在用戶態和內核態切換。另外，內核爲每一個線程都映射調度實體，若是系統出現大量線程，會對系統性能有影響。但該模型的實用性仍是高於多對一的線程模型。LinuxThread與NPTL都是採用這種模型。

在linux中經過LWP（lightweight process）做爲線程概念的支持，輕量級線程(LWP)是一種由內核支持的用戶線程。它是基於內核線程的高級抽象，所以只有先支持內核線程，纔能有LWP。每個進程有一個或多個LWPs，每一個LWP由一個內核線程支持。這種模型實際上就是恐龍書上所提到的一對一線程模型。在這種實現的操做系統中，LWP就是用戶線程。

因爲每一個LWP都與一個特定的內核線程關聯，所以每一個LWP都是一個獨立的線程調度單元。即便有一個LWP在系統調用中阻塞，也不會影響整個進程的執行。

輕量級進程具備侷限性。首先，大多數LWP的操做，如創建、析構以及同步，都須要進行系統調用。系統調用的代價相對較高：須要在user mode和kernel mode中切換。其次，每一個LWP都須要有一個內核線程支持，所以LWP要消耗內核資源（內核線程的棧空間）。所以一個系統不能支持大量的LWP。圖也是盜的。

 

 

 

2）「多對一模型」
多對一線程模型中，線程的建立、調度、同步的全部細節所有由進程的用戶空間線程庫來處理。用戶態線程的不少操做對內核來講都是透明的，由於不須要內核來接管，這意味不須要內核態和用戶態頻繁切換。線程的建立、調度、同步處理速度很是快。固然線程的一些其餘操做仍是要通過內核，如IO讀寫。這樣致使了一個問題：當多線程併發執行時，若是其中一個線程執行IO操做時，內核接管這個操做，若是IO阻塞，用戶態的其餘線程都會被阻塞，由於這些線程都對應同一個內核調度實體。在多處理器機器上，內核不知道用戶態有這些線程，沒法把它們調度到其餘處理器，也沒法經過優先級來調度。這對線程的使用是沒有意義的！

 

 

 

3）「多對多模型」

用戶線程庫仍是徹底創建在用戶空間中，所以用戶線程的操做仍是很廉價，所以能夠創建任意多須要的用戶線程。操做系統提供了 LWP 做爲用戶線程和內核線程之間的橋樑。 LWP 仍是和前面提到的同樣，具備內核線程支持，是內核的調度單元，而且用戶線程的系統調用要經過 LWP ，所以進程中某個用戶線程的阻塞不會影響整個進程的執行。用戶線程庫將創建的用戶線程關聯到 LWP 上， LWP 與用戶線程的數量不必定一致。當內核調度到某個 LWP 上時，此時與該 LWP 關聯的用戶線程就被執行。