內核線程 為什麼需要內核線程 Linux內核可以看作一個服務進程(管理軟硬體資源，響應用戶進程的種種合理以及不合理的請求)。 內核需要多個執行流並行，為了防止可能的阻塞，支持多線程是必要的。 內核線程就是內核的分身，一個分身可以處理一件特定事情。內核線程的調度由內核負責，一個內核線程處於阻塞狀態時不 ...
內核線程
為什麼需要內核線程
Linux內核可以看作一個服務進程(管理軟硬體資源，響應用戶進程的種種合理以及不合理的請求)。
內核需要多個執行流並行，為了防止可能的阻塞，支持多線程是必要的。
內核線程就是內核的分身，一個分身可以處理一件特定事情。內核線程的調度由內核負責，一個內核線程處於阻塞狀態時不影響其他的內核線程，因為其是調度的基本單位。
這與用戶線程是不一樣的。因為內核線程只運行在內核態
因此，它只能使用大於PAGE_OFFSET（傳統的x86_32上是3G）的地址空間。
內核線程概述
內核線程是直接由內核本身啟動的進程。內核線程實際上是將內核函數委托給獨立的進程，它與內核中的其他進程”並行”執行。內核線程經常被稱之為內核守護進程。
他們執行下列任務
- 周期性地將修改的記憶體頁與頁來源塊設備同步
- 如果記憶體頁很少使用，則寫入交換區
- 管理延時動作, 如２號進程接手內核進程的創建
- 實現文件系統的事務日誌
內核線程主要有兩種類型
- 線程啟動後一直等待，直至內核請求線程執行某一特定操作。
- 線程啟動後按周期性間隔運行，檢測特定資源的使用，在用量超出或低於預置的限制時採取行動。
內核線程由內核自身生成，其特點在於
- 它們在CPU的管態執行，而不是用戶態。
- 它們只可以訪問虛擬地址空間的內核部分（高於TASK_SIZE的所有地址），但不能訪問用戶空間
內核線程的進程描述符task_struct
task_struct進程描述符中包含兩個跟進程地址空間相關的欄位mm, active_mm
struct task_struct
{
// ...
struct mm_struct *mm;
struct mm_struct *avtive_mm;
//...
};大多數電腦上系統的全部虛擬地址空間分為兩個部分: 供用戶態程式訪問的虛擬地址空間和供內核訪問的內核空間。每當內核執行上下文切換時, 虛擬地址空間的用戶層部分都會切換, 以便當前運行的進程匹配, 而內核空間不會進行切換。
對於普通用戶進程來說，mm指向虛擬地址空間的用戶空間部分，而對於內核線程，mm為NULL。
這位優化提供了一些餘地, 可遵循所謂的惰性TLB處理(lazy TLB handing)。active_mm主要用於優化，由於內核線程不與任何特定的用戶層進程相關，內核並不需要倒換虛擬地址空間的用戶層部分，保留舊設置即可。由於內核線程之前可能是任何用戶層進程在執行，故用戶空間部分的內容本質上是隨機的，內核線程決不能修改其內容，故將mm設置為NULL，同時如果切換出去的是用戶進程，內核將原來進程的mm存放在新內核線程的active_mm中，因為某些時候內核必須知道用戶空間當前包含了什麼。
為什麼沒有mm指針的進程稱為惰性TLB進程?
假如內核線程之後運行的進程與之前是同一個, 在這種情況下, 內核並不需要修改用戶空間地址表。地址轉換後備緩衝器(即TLB)中的信息仍然有效。只有在內核線程之後, 執行的進程是與此前不同的用戶層進程時, 才需要切換(並對應清除TLB數據)。
內核線程和普通的進程間的區別在於內核線程沒有獨立的地址空間，mm指針被設置為NULL；它只在 內核空間運行，從來不切換到用戶空間去；並且和普通進程一樣，可以被調度，也可以被搶占。
內核線程的創建
創建內核線程介面的演變
內核線程可以通過兩種方式實現：
- 古老的介面 kernel_create和daemonize
將一個函數傳遞給kernel_thread創建並初始化一個task，該函數接下來負責幫助內核調用daemonize已轉換為內核守護進程，daemonize隨後完成一些列操作, 如該函數釋放其父進程的所有資源，不然這些資源會一直鎖定直到線程結束。阻塞信號的接收, 將init用作守護進程的父進程
- 更加現在的方法kthead_create和kthread_run
創建內核更常用的方法是輔助函數kthread_create，該函數創建一個新的內核線程。最初線程是停止的，需要使用wake_up_process啟動它。
使用kthread_run，與kthread_create不同的是，其創建新線程後立即喚醒它，其本質就是先用kthread_create創建一個內核線程，然後通過wake_up_process喚醒它
2號進程kthreadd的誕生
早期的kernel_create和daemonize介面
在早期的內核中, 提供了kernel_create和daemonize介面, 但是這種機制操作複雜而且將所有的任務交給內核去完成。
但是這種機制低效而且繁瑣, 將所有的操作塞給內核, 我們創建內核線程的初衷不本來就是為了內核分擔工作, 減少內核的開銷的麽
Workqueue機制
因此在linux-2.6以後, 提供了更加方便的介面kthead_create和kthread_run, 同時將內核線程的創建操作延後, 交給一個工作隊列workqueue, 參見http://lxr.linux.no/linux+v2.6.13/kernel/kthread.c#L21
Linux中的workqueue機制就是為了簡化內核線程的創建。通過kthread_create並不真正創建內核線程, 而是將創建工作create work插入到工作隊列helper_wq中, 隨後調用workqueue的介面就能創建內核線程。並且可以根據當前系統CPU的個數創建線程的數量，使得線程處理的事務能夠並行化。workqueue是內核中實現簡單而有效的機制，他顯然簡化了內核daemon的創建，方便了用戶的編程.
工作隊列（workqueue）是另外一種將工作推後執行的形式.工作隊列可以把工作推後，交由一個內核線程去執行，也就是說，這個下半部分可以在進程上下文中執行。最重要的就是工作隊列允許被重新調度甚至是睡眠。
具體的信息, 請參見
Linux workqueue工作原理
2號進程kthreadd
但是這種方法依然看起來不夠優美, 我們何不把這種創建內核線程的工作交給一個特殊的內核線程來做呢？
於是linux-2.6.22引入了kthreadd進程, 並隨後演變為2號進程, 它在系統初始化時同1號進程一起被創建(當然肯定是通過kernel_thread), 參見rest_init函數, 並隨後演變為創建內核線程的真正建造師, 參見kthreadd和kthreadd函數, 它會迴圈的是查詢工作鏈表static LIST_HEAD(kthread_create_list);中是否有需要被創建的內核線程, 而我們的通過kthread_create執行的操作, 只是在內核線程任務隊列kthread_create_list中增加了一個create任務, 然後會喚醒kthreadd進程來執行真正的創建操作
內核線程會出現在系統進程列表中, 但是在ps的輸出中進程名command由方括弧包圍, 以便與普通進程區分。
如下圖所示, 我們可以看到系統中, 所有內核線程都用[]標識, 而且這些進程父進程id均是2, 而2號進程kthreadd的父進程是0號進程
使用ps -eo pid,ppid,command
kernel_thread
kernel_thread是最基礎的創建內核線程的介面, 它通過將一個函數直接傳遞給內核來創建一個進程, 創建的進程運行在內核空間, 並且與其他進程線程共用內核虛擬地址空間
kernel_thread的實現經歷過很多變革
早期的kernel_thread執行更底層的操作, 直接創建了task_struct併進行初始化,
引入了kthread_create和kthreadd 2號進程後, kernel_thread的實現也由統一的_do_fork(或者早期的do_fork)托管實現
早期實現
早期的內核中, kernel_thread並不是使用統一的do_fork或者_do_fork這一封裝好的介面實現的, 而是使用更底層的細節
參見
http://lxr.free-electrons.com/source/kernel/fork.c?v=2.4.37#L613
我們可以看到它內部調用了更加底層的arch_kernel_thread創建了一個線程
arch_kernel_thread
其具體實現請參見
http://lxr.free-electrons.com/ident?v=2.4.37;i=arch_kernel_thread
但是這種方式創建的線程並不適合運行，因此內核提供了daemonize函數, 其聲明在include/linux/sched.h中
// http://lxr.free-electrons.com/source/include/linux/sched.h?v=2.4.37#L800
extern void daemonize(void);定義在kernel/sched.c
http://lxr.free-electrons.com/source/kernel/sched.c?v=2.4.37#L1326
主要執行如下操作
- 該函數釋放其父進程的所有資源，不然這些資源會一直鎖定直到線程結束。
- 阻塞信號的接收
- 將init用作守護進程的父進程
我們可以看到早期內核的很多地方使用了這個介面, 比如
可以參見
http://lxr.free-electrons.com/ident?v=2.4.37;i=daemonize
我們將了這麼多kernel_thread, 但是我們並不提倡我們使用它, 因為這個是底層的創建內核線程的操作介面, 使用kernel_thread在內核中執行大量的操作, 雖然創建的代價已經很小了, 但是對於追求性能的linux內核來說還不能忍受
因此我們只能說kernel_thread是一個古老的介面, 內核中的有些地方仍然在使用該方法, 將一個函數直接傳遞給內核來創建內核線程
新版本的實現
於是linux-3.x下之後, 有了更好的實現, 那就是
延後內核的創建工作, 將內核線程的創建工作交給一個內核線程來做, 即kthreadd 2號進程
但是在kthreadd還沒創建之前, 我們只能通過kernel_thread這種方式去創建, 同時kernel_thread的實現也改為由_do_fork(早期內核中是do_fork)來實現, 參見kernel/fork.c
pid_t kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
{
return _do_fork(flags|CLONE_VM|CLONE_UNTRACED, (unsigned long)fn,
(unsigned long)arg, NULL, NULL, 0);
}kthread_create
struct task_struct *kthread_create_on_node(int (*threadfn)(void *data),
void *data,
int node,
const char namefmt[], ...);
#define kthread_create(threadfn, data, namefmt, arg...) \
kthread_create_on_node(threadfn, data, NUMA_NO_NODE, namefmt, ##arg)創建內核更常用的方法是輔助函數kthread_create，該函數創建一個新的內核線程。最初線程是停止的，需要使用wake_up_process啟動它。
kthread_run
/**
* kthread_run - create and wake a thread.
* @threadfn: the function to run until signal_pending(current).
* @data: data ptr for @threadfn.
* @namefmt: printf-style name for the thread.
*
* Description: Convenient wrapper for kthread_create() followed by
* wake_up_process(). Returns the kthread or ERR_PTR(-ENOMEM).
*/
#define kthread_run(threadfn, data, namefmt, ...) \
({ \
struct task_struct *__k \
= kthread_create(threadfn, data, namefmt, ## __VA_ARGS__); \
if (!IS_ERR(__k)) \
wake_up_process(__k); \
__k; \
})內核線程的退出
線程一旦啟動起來後，會一直運行，除非該線程主動調用do_exit函數，或者其他的進程調用kthread_stop函數，結束線程的運行。
int kthread_stop(struct task_struct *thread);kthread_stop() 通過發送信號給線程。
如果線程函數正在處理一個非常重要的任務，它不會被中斷的。當然如果線程函數永遠不返回並且不檢查信號，它將永遠都不會停止。
在執行kthread_stop的時候，目標線程必須沒有退出，否則會Oops。原因很容易理解，當目標線程退出的時候，其對應的task結構也變得無效，kthread_stop引用該無效task結構就會出錯。
為了避免這種情況，需要確保線程沒有退出，其方法如代碼中所示：
thread_func()
{
// do your work here
// wait to exit
while(!thread_could_stop())
{
wait();
}
}
exit_code()
{
kthread_stop(_task); //發信號給task，通知其可以退出了
}這種退出機制很溫和，一切盡在thread_func()的掌控之中，線程在退出時可以從容地釋放資源，而不是莫名其妙地被人“暗殺”。
