內核線程的作用主要有:
周期性的將dirty內存頁同步到磁盤設備上。 比如 bpflush線程周期性的把dirty數據寫回磁盤內存頁很少的情況下,把內存page 交換到磁盤空間。 比如kswapd,系統會為每一個NUMA創建一個kswapd進程,但是在非NUMA系統上,則僅有一個kswapd管理延時動作實現文件系統的事物日志主要包括兩種類型的內核線程:
線程按周期性間隔運行,檢測特定資源的使用,在用量超出或者低于預置的限制時采取行動在線程啟動后則一直等待,直到內核線程請求執行某一特定的操作。同時內核線程是由內核自己創建的線程,也叫做守護線程(deamon)。在終端上用命令”ps -Al”列出的所有進程中,名字以k開關以d結尾的往往都是內核線程,比如kthreadd、kswapd。
既然是內核線程是一個單獨的概念,那么與用戶線程之間一定存在某些區別,
內核線程與用戶線程的相同點是:
都由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)函數完成的。但這個問題還存在很多的問題。
在linux2.6之后,為了完全兼容posix標準,linux2.6首先對內核進行了改進,引入了線程組的概念(仍然用輕量級進程表示線程),有了這個概念就可以將一組線程組織稱為一個進程,如此通過這個改變,linux內核正式支持多線程特性。以上是邏輯上的改變,在實現上主要的改變就是在task_struct中加入tgid字段,這個字段就是用于表示線程組id的字段。在用戶線程庫方面,也使用NPTL代替LinuxThread。不同調度模型上仍然采用“1對1”模型
現在在支持多線程的操作系統中一般采用三種調度模型,分別是“一對一模型”、“多對一模型”、“多對多模型”。
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 關聯的用戶線程就被執行。
新聞熱點
疑難解答