工作隊列linux
㈠ 關於linux下的select/epoll
select這個系統調用的原型如下
第一個參數nfds用來告訴內核 要掃描的socket fd的數量+1 ，select系統調用最大接收的數量是1024，但是如果每次都去掃描1024，實際上的數量並不多，則效率太低，這里可以指定需要掃描的數量。 最大數量為1024，如果需要修改這個數量，則需要重新編譯Linux內核源碼。
第2、3、4個參數分別是readfds、writefds、exceptfds，傳遞的參數應該是fd_set 類型的引用，內核會檢測每個socket的fd， 如果沒有讀事件，就將對應的fd從第二個參數傳入的fd_set中移除，如果沒有寫事件，就將對應的fd從第二個參數的fd_set中移除，如果沒有異常事件，就將對應的fd從第三個參數的fd_set中移除 。這里我們應該 要將實際的readfds、writefds、exceptfds拷貝一份副本傳進去，而不是傳入原引用，因為如果傳遞的是原引用，某些socket可能就已經丟失 。
最後一個參數是等待時間， 傳入0表示非阻塞，傳入>0表示等待一定時間，傳入NULL表示阻塞，直到等到某個socket就緒 。
FD_ZERO()這個函數將fd_set中的所有bit清0，一般用來進行初始化等。
FD_CLR()這個函數用來將bitmap(fd_set )中的某個bit清0，在客戶端異常退出時就會用到這個函數，將fd從fd_set中刪除。
FD_ISSET()用來判斷某個bit是否被置1了，也就是判斷某個fd是否在fd_set中。
FD_SET()這個函數用來將某個fd加入fd_set中，當客戶端新加入連接時就會使用到這個函數。
epoll_create系統調用用來創建epfd，會在開辟一塊內存空間(epoll的結構空間)。size為epoll上能關注的最大描述符數，不夠會進行擴展，size只要＞0就行，早期的設計size是固定大小，但是現在size參數沒什麼用，會自動擴展。
返回值是epfd，如果為-1則說明創建epoll對象失敗 。
第一個參數epfd傳入的就是epoll_create返回的epfd。
第二個參數傳入對應操作的宏，包括 增刪改(EPOLL_CTL_ADD、EPOLL_CTL_DEL、EPOLL_CTL_MOD) 。
第三個參數傳入的是 需要增刪改的socket的fd 。
第四個參數傳入的是 需要操作的fd的哪些事件 ，具體的事件可以看後續。
返回值是一個int類型，如果為-1則說明操作失敗 。
第一個參數是epfd，也就是epoll_create的返回值。
第二個參數是一個epoll_event類型的指針，也就是傳入的是一個數組指針。 內核會將就緒的socket的事件拷貝到這個數組中，用戶可以根據這個數組拿到事件和消息等 。
第三個參數是maxevents，傳入的是 第二個參數的數組的容量 。
第四個參數是timeout， 如果設為-1一直阻塞直到有就緒數據為止，如果設為0立即返回，如果＞0那麼阻塞一段時間 。
返回值是一個int類型，也就是就緒的socket的事件的數量(內核拷貝給用戶的events的元素的數量)，通過這個數量可以進行遍歷處理每個事件 。
一般需要傳入 ev.data.fd 和 ev.events ，也就是fd和需要監控的fd的事件。事件如果需要傳入多個，可以通過按位與來連接，比如需要監控讀寫事件，只需要像如下這樣操作即可： ev.events=EPOLLIN | EPOLLOUT 。
LT(水平觸發)， 默認 的工作模式， 事件就緒後用戶可以選擇處理和不處理，如果用戶不處理，內核會對這部分數據進行維護，那麼下次調用epoll_wait()時仍舊會打包出來 。
ET(邊緣觸發)，事件就緒之後， 用戶必須進行處理 ，因為內核把事件打包出來之後就把對應的就緒事件給清掉了， 如果不處理那麼就緒事件就沒了 。ET可以減少epoll事件被重復觸發的次數，效率比LT高。
如果需要設置為邊緣觸發只需要設置事件為類似 ev.events=EPOLLIN | EPOLLET 即可 。
select/poll/epoll是nio多路復用技術， 傳統的bio無法實現C10K/C100K ，也就是無法滿足1w/10w的並發量，在這么高的並發量下，在進行上下文切換就很容易將伺服器的負載拉飛。
1.將fd_set從用戶態拷貝到內核態
2.根據fd_set掃描內存中的socket的fd的狀態，時間復雜度為O(n)
3.檢查fd_set，如果有已經就緒的socket，就給對應的socket的fd打標記，那麼就return 就緒socket的數量並喚醒當前線程，如果沒有就緒的socket就繼續阻塞當前線程直到有socket就緒才將當前線程喚醒。
4.如果想要獲取當前已經就緒的socket列表，則還需要進行一次系統調用，使用O(n)的時間去掃描socket的fd列表，將已經打上標記的socket的fd返回。
CPU在同一個時刻只能執行一個程序，通過RR時間片輪轉去切換執行各個程序。沒有被掛起的進程(線程)則在工作隊列中排隊等待CPU的執行，將進程(線程)從工作隊列中移除就是掛起，反映到Java層面的就是線程的阻塞。
什麼是中斷？當我們使用鍵盤、滑鼠等IO設備的時候，會給主板一個電流信號，這個電流信號就給CPU一個中斷信號，CPU執行完當前的指令便會保存現場，然後執行鍵盤/滑鼠等設備的中斷程序，讓中斷程序獲取CPU的使用權，在中斷程序後又將現場恢復，繼續執行之前的進程。
如果第一次沒檢測到就緒的socket，就要將其進程(線程)從工作隊列中移除，並加入到socket的等待隊列中。
socket包含讀緩沖區+寫緩沖區+等待隊列(放線程或eventpoll對象)
當從客戶端往伺服器端發送數據時，使用TCP/IP協議將通過物理鏈路、網線發給伺服器的網卡設備，網卡的DMA設備將接收到的的數據寫入到內存中的一塊區域(網卡緩沖區)，然後會給CPU發出一個中斷信號，CPU執行完當前指令則會保存現場，然後網卡的中斷程序就獲得了CPU的使用權，然後CPU便開始執行網卡的中斷程序，將內存中的緩存區中的數據包拿出，判斷埠號便可以判斷它是哪個socket的數據，將數據包寫入對應的socket的讀(輸入)緩沖區，去檢查對應的socket的等待隊列有沒有等待著的進程(線程)，如果有就將該線程(進程)從socket的等待隊列中移除，將其加入工作隊列，這時候該進程(線程)就再次擁有了CPU的使用許可權，到這里中斷程序就結束了。
之後這個進程(線程)就執行select函數再次去檢查fd_set就能發現有socket緩沖區中有數據了，就將該socket的fd打標記，這個時候select函數就執行完了，這時候就會給上層返回一個int類型的數值，表示已經就緒的socket的數量或者是發生了錯誤。這個時候就再進行內核態到用戶態的切換，對已經打標記的socket的fd進行處理。
將原本1024bit長度的bitmap(fd_set)換成了數組的方式傳入 ，可以 解決原本1024個不夠用的情況 ，因為傳入的是數組，長度可以不止是1024了，因此socket數量可以更多，在Kernel底層會將數組轉換成鏈表。
在十多年前，linux2.6之前，不支持epoll，當時可能會選擇用Windows/Unix用作伺服器，而不會去選擇Linux，因為select/poll會隨著並發量的上升，性能變得越來越低，每次都得檢查所有的Socket列表。
1.select/poll每次調用都必須根據提供所有的socket集合，然後就 會涉及到將這個集合從用戶空間拷貝到內核空間，在這個過程中很耗費性能 。但是 其實每次的socket集合的變化也許並不大，也許就1-2個socket ，但是它會全部進行拷貝，全部進行遍歷一一判斷是否就緒。
2.select/poll的返回類型是int，只能代表當前的就緒的socket的數量/發生了錯誤， 如果還需要知道是哪些socket就緒了，則還需要再次使用系統調用去檢查哪些socket是就緒的，又是一次O(n)的操作，很耗費性能 。
1.epoll在Kernel內核中存儲了對應的數據結構(eventpoll)。我們可以 使用epoll_create()這個系統調用去創建一個eventpoll對象 ，並返回eventpoll的對象id(epfd)，eventpoll對象主要包括三個部分：需要處理的正在監聽的socket_fd列表(紅黑樹結構)、socket就緒列表以及等待隊列(線程)。
2.我們可以使用epoll_ctl()這個系統調用對socket_fd列表進行CRUD操作，因為可能頻繁地進行CRUD，因此 socket_fd使用的是紅黑樹的結構 ，讓其效率能更高。epoll_ctl()傳遞的參數主要是epfd(eventpoll對象id)。
3.epoll_wait()這個系統調用默認會 將當前進程(線程)阻塞，加入到eventpoll對象的等待隊列中，直到socket就緒列表中有socket，才會將該進程(線程)重新加入工作隊列 ，並返回就緒隊列中的socket的數量。
socket包含讀緩沖區、寫緩沖區和等待隊列。當使用epoll_ctl()系統調用將socket新加入socket_fd列表時，就會將eventpoll對象引用加到socket的等待隊列中， 當網卡的中斷程序發現socket的等待隊列中不是一個進程(線程)，而是一個eventpoll對象的引用，就將socket引用追加到eventpoll對象的就緒列表的尾部 。而eventpoll對象中的等待隊列存放的就是調用了epoll_wait()的進程(線程)，網卡的中斷程序執行會將等待隊列中的進程(線程)重新加入工作隊列，讓其擁有佔用CPU執行的資格。epoll_wait()的返回值是int類型，返回的是就緒的socket的數量/發生錯誤，-1表示發生錯誤。
epoll的參數有傳入一個epoll_event的數組指針(作為輸出參數)，在調用epoll_wait()返回的同時，Kernel內核還會將就緒的socket列表添加到epoll_event類型的數組當中。
㈡ 在linux編程中若一個用戶程序希望將一組數據傳遞給kernel有幾種方式
教科書里的Linux代碼例子都已作古，所以看到的代碼不能當真，領會意思就行了
比如以前的init進程的啟動代碼
execve(init_filename,argv_init,envp_init);
現在改為
static void run_init_process(char *init_filename)
{
argv_init[0] = init_filename;
kernel_execve(init_filename, argv_init, envp_init);
}
好的，聰明人就發現，linux內核中調用用戶空間的程序可以使用init這樣的方式，調用 kernel_execve
不過內核還是提供了更好的輔助介面call_usermodehelper，自然最後也是調用kernel_execve
調用特定的內核函數（系統調用）是 GNU/Linux 中軟體開發的原本就有的組成部分。但如果方向反過來呢，內核空間調用用戶空間？確實有一些有這種特性的應用程序需要每天使用。例如，當內核找到一個設備， 這時需要載入某個模塊，進程如何處理？動態模塊載入在內核通過 usermode-helper 進程進行。
讓我們從探索 usermode-helper 應用程序編程介面（API）以及在內核中使用的例子開始。 然後，使用 API 構造一個示例應用程序，以便更好地理解其工作原理與局限。
usermode-helper API
usermode-helper API 是個很簡單的 API，其選項為用戶熟知。例如，要創建一個用戶空間進程，通常只要設置名稱為 executable，選項都為 executable，以及一組環境變數（指向 execve 主頁）。創建內核進程也是一樣。但由於創建內核空間進程，還需要設置一些額外選項。
內核版本
本文探討的是 2.6.27 版內核的 usermode-helper API。
表 1 展示的是 usermode-helper API 中一組關鍵的內核函數
表 1. usermode-helper API 中的核心函數
API 函數
描述
call_usermodehelper_setup 准備 user-land 調用的處理函數
call_usermodehelper_setkeys 設置 helper 的會話密鑰
call_usermodehelper_setcleanup 為 helper 設置一個清空函數
call_usermodehelper_stdinpipe 為 helper 創建 stdin 管道
call_usermodehelper_exec 調用 user-land
表 2 中還有一些簡化函數，它們封裝了的幾個內核函數（用一個調用代替多個調用）。這些簡化函數在很多情況下都很有用，因此盡可能使用他們。
表 2. usermode-helper API 的簡化
API 函數
描述
call_usermodehelper 調用 user-land
call_usermodehelper_pipe 使用 stdin 管道調用 user-land
call_usermodehelper_keys 使用會話密鑰調用 user-land
讓我們先瀏覽一遍這些核心函數，然後探索簡化函數提供了哪些功能。核心 API 使用了一個稱為subprocess_info 結構的處理函數引用進行操作。該結構（可在 ./kernel/kmod.c 中找到）集合了給定的 usermode-helper 實例的所有必需元素。該結構引用從 call_usermodehelper_setup 調用返回。該結構（以及後續調用）將會在 call_usermodehelper_setkeys（用於存儲憑證）、call_usermodehelper_setcleanup 以及 call_usermodehelper_stdinpipe 的調用中進一步配置。最後，一旦配置完成，就可通過調用 call_usermodehelper_exec 來調用配置好的用戶模式應用程序。
聲明
該方法提供了一個從內核調用用戶空間應用程序必需的函數。盡管這項功能有合理用途，還應仔細考慮是否需要其他實現。這是一個方法，但其他方法會更合適。
核心函數提供了最大程度的控制，其中 helper 函數在單個調用中完成了大部分工作。管道相關調用（call_usermodehelper_stdinpipe 和 helper 函數 call_usermodehelper_pipe）創建了一個相聯管道供 helper 使用。具體地說，創建了管道（內核中的文件結構）。用戶空間應用程序對管道可讀，內核對管道可寫。對於本文，核心轉儲只是使用 usermode-helper 管道的應用程序。在該應用程序（./fs/exec.c do_coremp()）中，核心轉儲通過管道從內核空間寫到用戶空間。
這些函數與 sub_processinfo 以及 subprocess_info 結構的細節之間的關系如圖 1 所示。
圖 1. Usermode-helper API 關系
表 2 中的簡化函數內部執行 call_usermodehelper_setup 函數和 call_usermodehelper_exec 函數。表 2 中最後兩個調用分別調用的是 call_usermodehelper_setkeys 和 call_usermodehelper_stdinpipe。可以在 ./kernel/kmod.c 找到 call_usermodehelper_pipe 和 call_usermodehelper 的代碼，在 ./include/linux/kmod.h 中找到 call_usermodhelper_keys 的代碼。
為什麼要從內核調用用戶空間應用程序？
現在讓我們看一看 usermode-helper API 所使用的內核空間。表 3 提供的並不是專門的應用程序列表，而是一些有趣應用的示例。
表 3. 內核中的 usermode-helper API 應用程序
應用程序
源文件位置
內核模塊調用 ./kernel/kmod.c
電源管理 ./kernel/sys.c
控制組 ./kernel/cgroup.c
安全密匙生成 ./security/keys/request_key.c
內核事件交付 ./lib/kobject_uevent.c
最直接的 usermode-helper API 應用程序是從內核空間載入內核模塊。request_mole 函數封裝了 usermode-helper API 的功能並提供了簡單的介面。在一個常用的模塊中，內核指定一個設備或所需服務並調用 request_mole 來載入模塊。通過使用 usermode-helper API，模塊通過 modprobe 載入到內核（應用程序通過 request_mole 在用戶空間被調用）。
與模塊載入類似的應用程序是設備熱插拔（在運行時添加或刪除設備）。該特性是通過使用 usermode-helper API，調用用戶空間的 /sbin/hotplug 工具實現的。
關於 usermode-helper API 的一個有趣的應用程序（通過 request_mole） 是文本搜索 API（./lib/textsearch.c）。該應用程序在內核中提供了一個可配置的文本搜索基礎架構。該應用程序使用 usermode-helper API 將搜索演算法當作可載入模塊進行動態載入。在 2.6.30 內核版本中，支持三個演算法，包括 Boyer-Moore（./lib/ts_bm.c），簡單固定狀態機方法（./lib/ts_fsm.c），以及 Knuth-Morris-Pratt 演算法（./lib/ts_kmp.c）。
usermode-helper API 還支持 Linux 按照順序關閉系統。當需要系統關閉電源時，內核調用用戶空間的 /sbin/poweroff 命令來完成。其他應用程序如 表 3 所示，表中附有其源文件位置。
Usermode-helper API 內部
在 kernel/kmod.c 中可以找到 usermode-helper API 的源代碼 和 API（展示了主要的用作內核空間的內核模塊載入器）。這個實現使用 kernel_execve 完成臟工作（dirty work）。請注意 kernel_execve是在啟動時開啟 init 進程的函數，而且未使用 usermode-helper API。
usermode-helper API 的實現相當簡單直觀（見圖 2）。usermode-helper 從調用call_usermodehelper_exec 開始執行（它用於從預先配置好的 subprocess_info 結構中清除用戶空間應用程序）。該函數接受兩個參數：subprocess_info 結構引用和一個枚舉類型（不等待、等待進程中止及等待進程完全結束）。subprocess_info（或者是，該結構的 work_struct 元素）然後被壓入工作隊列（khelper_wq），然後隊列非同步執行調用。
圖 2. usermode-helper API 內部實現
當一個元素放入 khelper_wq 時，工作隊列的處理函數就被調用（本例中是__call_usermodehelper），它在 khelper 線程中運行。該函數從將 subprocess_info 結構出隊開始，此結構包含所有用戶空間調用所需信息。該路徑下一步取決於 wait 枚舉變數。如果請求者想要等整個進程結束，包含用戶空間調用（UMH_WAIT_PROC）或者是根本不等待（UMH_NO_WAIT），那麼會從 wait_for_helper 函數創建一個內核線程。否則，請求者只是等待用戶空間應用程序被調用（UMH_WAIT_EXEC），但並不完全。這種情況下，會為____call_usermodehelper() 創建一個內核線程。
在 wait_for_helper 線程中，會安裝一個 SIGCHLD 信號處理函數，並為 ____call_usermodehelper 創建另一個內核線程。但在 wait_for_helper 線程中，會調用 sys_wait4 來等待____call_usermodehelper 內核線程（由 SIGCHLD 信號指示）結束。然後線程執行必要的清除工作（為UMH_NO_WAIT 釋放結構空間或簡單地向 call_usermodehelper_exec() 回送一個完成報告）。
函數 ____call_usermodehelper 是實際讓應用程序在用戶空間啟動的地方。該函數首先解鎖所有信號並設置會話密鑰環。它還安裝了 stdin 管道（如果有請求）。進行了一些安裝以後，用戶空間應用程序通過 kernel_execve（來自 kernel/syscall.c）被調用，此文件包含此前定義的 path、argv 清單（包含用戶空間應用程序名稱）以及環境。當該進程完成後，此線程通過調用 do_exit() 而產生。
該進程還使用了 Linux 的 completion，它是像信號一樣的操作。當 call_usermodehelper_exec 函數被調用後，就會聲明 completion。當 subprocess_info 結構放入 khelper_wq 後，會調用wait_for_completion（使用 completion 變數作為參數）。請注意此變數會存儲到 subprocess_info 結構作為 complete 欄位。當子線程想要喚醒 call_usermodehelper_exec 函數，會調用內核方法complete，並判斷來自 subprocess_info 結構的 completion 變數。該調用會解鎖此函數使其能繼續。可以在 include/linux/completion.h 中找到 API 的實現。
應用程序示例
現在，讓我們看看 usermode-helper API 的簡單應用。首先看一下標准 API，然後學習如何使用 helper 函數使事情更簡單。
在該例中，首先開發了一個簡單的調用 API 的可載入內核模塊。清單 1 展示了樣板模塊功能，定義了模塊入口和出口函數。這兩個函數根據模塊的 modprobe（模塊入口函數）或 insmod（模塊入口函數），以及 rmmod（模塊出口函數）被調用。
清單 1. 模塊樣板函數
#include
#include
#include
MODULE_LICENSE( "GPL" );
static int __init mod_entry_func( void )
{
return umh_test();
}
static void __exit mod_exit_func( void )
{
return;
}
mole_init( mod_entry_func );
mole_exit( mod_exit_func );
usermode-helper API 的使用如 清單 2 所示，其中有詳細描述。函數開始是聲明所需變數和結構。以subprocess_info 結構開始，它包含所有的執行用戶空間調用的信息。該調用在調用call_usermodehelper_setup 時初始化。下一步，定義參數列表，使 argv 被調用。該列表與普通 C 程序中的 argv 列表類似，定義了應用程序（數組第一個元素）和參數列表。需要 NULL 終止符來提示列表末尾。請注意這里的 argc 變數（參數數量）是隱式的，因為 argv 列表的長度已經知道。該例中，應用程序名是 /usr/bin/logger，參數是 help!，然後是 NULL 終止符。下一個所需變數是環境數組（envp）。該數組是一組定義用戶空間應用程序執行環境的參數列表。本例中，定義一些常用的參數，這些參數用於定義 shell 並以 NULL 條目結束。
清單 2. 簡單的 usermode_helper API 測試
static int umh_test( void )
{
struct subprocess_info *sub_info;
char *argv[] = { "/usr/bin/logger", "help!", NULL };
static char *envp[] = {
"HOME=/",
"TERM=linux",
"PATH=/sbin:/bin:/usr/sbin:/usr/bin", NULL };
sub_info = call_usermodehelper_setup( argv[0], argv, envp, GFP_ATOMIC );
if (sub_info == NULL) return -ENOMEM;
return call_usermodehelper_exec( sub_info, UMH_WAIT_PROC );
}
下一步，調用 call_usermodehelper_setup 來創建已初始化的 subprocess_info 結構。請注意使用了先前初始化的變數以及指示用於內存初始化的 GFP 屏蔽第四個參數。在安裝函數內部，調用了kzalloc（分配內核內存並清零）。該函數需要 GFP_ATOMIC 或 GFP_KERNEL 標志（前者定義調用不可以休眠，後者定義可以休眠）。快速測試新結構（即，非 NULL）後，使用 call_usermodehelper_exec 函數繼續調用。該函數使用 subprocess_info 結構以及定義是否等待的枚舉變數（在 「Usermode-helper API 內部」 一節中有描述）。全部完成！ 模塊一旦載入，就可以在 /var/log/messages 文件中看到信息。
還可以通過 call_usermodehelper API 函數進一步簡化進程，它同時執行 call_usermodehelper_setup和 call_usermodehelper_exec 函數。如清單 3 所示，它不僅刪除函數，還消除了調用者管理subprocess_info 結構的必要性。
清單 3. 更簡單的 usermode-helper API 測試
static int umh_test( void )
{
char *argv[] = { "/usr/bin/logger", "help!", NULL };
static char *envp[] = {
"HOME=/",
"TERM=linux",
"PATH=/sbin:/bin:/usr/sbin:/usr/bin", NULL };
return call_usermodehelper( argv[0], argv, envp, UMH_WAIT_PROC );
}
請注意在清單 3 中，有著同樣的安裝並調用（例如初始化 argv 和 envp 數組）的需求。此處惟一的區別是 helper 函數執行 setup 和 exec 函數。
㈢ Linux 工作隊列和等待隊列的區別
work queue是一種bottom half，中斷處理的後半程，強調的是動態的概念，即work是重點，而queue是其次。
wait queue是一種「任務隊列」，可以把一些進程放在上面睡眠等待某個事件，強調靜態多一些，重點在queue上，即它就是一個queue，這個queue如何調度，什麼時候調度並不重要
等待隊列在內核中有很多用途，尤其適合用於中斷處理，進程同步及定時。這里只說，進程經常必須等待某些事件的發生。例如，等待一個磁碟操作的終止，等待釋放系統資源，或者等待時間經過固定的間隔。
等待隊列實現了在事件上的條件等待，希望等待特定事件的進程把放進合適的等待隊列，並放棄控制權。因此。等待隊列表示一組睡眠的進程，當某一條件為真時，由內核喚醒進程。
等待隊列由循環鏈表實現，其元素包括指向進程描述符的指針。每個等待隊列都有一個等待隊列頭，等待隊列頭是一個類型為wait_queue_head_t的數據結構。
等待隊列鏈表的每個元素代表一個睡眠進程，該進程等待某一事件的發生，描述符地址存放在task欄位中。然而，要喚醒等待隊列中所有的進程有時並不方便。例如，如果兩個或多個進程在等待互斥訪問某一個要釋放的資源，僅喚醒等待隊列中一個才有意義。這個進程佔有資源，而其他進程繼續睡眠可以用DECLARE_WAIT_QUEUE_HEAD(name)宏定義一個新的等待隊列，該宏靜態地聲明和初始化名為name的等待隊列頭變數。 init_waitqueue_head()函數用於初始化已動態分配的wait queue head變數等待隊列可以通過DECLARE_WAITQUEUE()靜態創建，也可以用init_waitqueue_head()動態創建。進程放入等待隊列並設置成不可執行狀態。
工作隊列，workqueue，它允許內核代碼來請求在將來某個時間調用一個函數。用來處理不是很緊急事件的回調方式處理方法.工作隊列的作用就是把工作推後,交由一個內核線程去執行，更直接的說就是寫了一個函數,而現在不想馬上執行它，需要在將來某個時刻去執行，那就得用工作隊列准沒錯。
如果需要用一個可以重新調度的實體來執行下半部處理，也應該使用工作隊列。是唯一能在進程上下文運行的下半部實現的機制。這意味著在需要獲得大量的內存時、在需要獲取信號量時，在需要執行阻塞式的I/O操作時，都會非常有用。
㈣ linux定時器和延時工作隊列的區別
工作隊列中是即將要調度到的任務隊列，等待隊列是暫時被掛起的任務隊列，或者有些任務無事可做休眠狀態的任務，它們會在某些條件觸發時恢復換入工作隊列並進入執行狀態，同樣在工作隊列中的任務在某個時刻也可以被換入到等待隊列中
㈤ Linux進程的調度
上回書說到 Linux進程的由來 和 Linux進程的創建 ，其實在同一時刻只能支持有限個進程或線程同時運行(這取決於CPU核數量，基本上一個進程對應一個CPU)，在一個運行的操作系統上可能運行著很多進程，如果運行的進程占據CPU的時間很長，就有可能導致其他進程餓死。為了解決這種問題，操作系統引入了 進程調度器 來進行進程的切換，輪流讓各個進程使用CPU資源。
1）rq： 進程的運行隊列( runqueue)， 每個CPU對應一個 ，包含自旋鎖(spinlock)、進程數量、用於公平調度的CFS信息結構、當前運行的進程描述符等。實際的進程隊列用紅黑樹來維護(通過CFS信息結構來訪問)。
2）cfs_rq： cfs調度的進程運行隊列信息 ，包含紅黑樹的根結點、正在運行的進程指針、用於負載均衡的葉子隊列等。
3）sched_entity： 把需要調度的東西抽象成調度實體 ，調度實體可以是進程、進程組、用戶等。這里包含負載權重值、對應紅黑樹結點、 虛擬運行時vruntime 等。
4）sched_class：把 調度策略(演算法)抽象成調度類 ，包含一組通用的調度操作介面。介面和實現是分離，可以根據調度介面去實現不同的調度演算法，使一個Linux調度程序可以有多個不同的調度策略。
1） 關閉內核搶占 ，初始化部分變數。獲取當前CPU的ID號，並賦值給局部變數CPU， 使rq指向CPU對應的運行隊列 。 標識當前CPU發生任務切換 ，通知RCU更新狀態，如果當前CPU處於rcu_read_lock狀態，當前進程將會放入rnp-> blkd_tasks阻塞隊列，並呈現在rnp-> gp_tasks鏈表中。 關閉本地中斷 ，獲取所要保護的運行隊列的自旋鎖， 為查找可運行進程做准備 。
2） 檢查prev的狀態，更新運行隊列 。如果不是可運行狀態，而且在內核態沒被搶占，應該從運行隊列中 刪除prev進程 。如果是非阻塞掛起信號，而且狀態為TASK_INTER-RUPTIBLE，就把該進程的狀態設置為TASK_RUNNING，並將它 插入到運行隊列 。
3）task_on_rq_queued(prev) 將pre進程插入到運行隊列的隊尾。
4）pick_next_task 選取將要執行的next進程。
5）context_switch(rq, prev, next)進行 進程上下文切換 。
1) 該進程分配的CPU時間片用完。
2) 該進程主動放棄CPU(例如IO操作)。
3) 某一進程搶佔CPU獲得執行機會。
Linux並沒有使用x86 CPU自帶的任務切換機制，需要通過手工的方式實現了切換。
進程創建後在內核的數據結構為task_struct ， 該結構中有掩碼屬性cpus_allowed，4個核的CPU可以有4位掩碼，如果CPU開啟超線程，有一個8位掩碼，進程可以運行在掩碼位設置為1的CPU上。
Linux內核API提供了兩個系統調用 ，讓用戶可以修改和查看當前的掩碼：
1) sched_setaffinity()：用來修改位掩碼。
2) sched_getaffinity()：用來查看當前的位掩碼。
在下次task被喚醒時，select_task_rq_fair根據cpu_allowed里的掩碼來確定將其置於哪個CPU的運行隊列，一個進程在某一時刻只能存在於一個CPU的運行隊列里。
在Nginx中，使用了CPU親和度來完成某些場景的工作：
worker_processes 4;
worker_cpu_affinity 0001001001001000;
上面這個配置說明了4個工作進程中的每一個和一個CPU核掛鉤。如果這個內容寫入Nginx的配置文件中，然後Nginx啟動或者重新載入配置的時候，若worker_process是4，就會啟用4個worker，然後把worker_cpu_affinity後面的4個值當作4個cpu affinity mask，分別調用ngx_setaffinity，然後就把4個worker進程分別綁定到CPU0～3上。
worker_processes 2;
worker_cpu_affinity 01011010;
上面這個配置則說明了兩個工作進程中的每一個和2個核掛鉤。