隨著2.6內核對epoll的完全支持，網絡上很多的文章和示例代碼都提供了這樣一個信息：使用epoll代替傳統的poll能給網絡服務應用帶來性能上 的提升。但大多文章里關于性能提升的原因解釋的較少，這里我將試分析一下內核（2.6.21.1）代碼中poll與epoll的工作原理，然后再通過一些 測試數據來對比具體效果。

   POLL：

   先說poll，poll或select為大部分Unix/Linux程序員所熟悉，這倆個東西原理類似，性能上也不存在明顯差異，但select對所監控的文件描述符數量有限制，所以這里選用poll做說明。

   poll是一個系統調用，其內核入口函數為sys_poll，sys_poll幾乎不做任何處理直接調用do_sys_poll，do_sys_poll的執行過程可以分為三個部分：

   1，將用戶傳入的pollfd數組拷貝到內核空間，因為拷貝操作和數組長度相關，時間上這是一個O（n）操作，這一步的代碼在do_sys_poll中包括從函數開始到調用do_poll前的部分。

   2，查詢每個文件描述符對應設備的狀態，如果該設備尚未就緒，則在該設備的等待隊列中加入一項并繼續查詢下一設備的狀態。查詢完所有設備后如果沒有一個設 備就緒，這時則需要掛起當前進程等待，直到設備就緒或者超時，掛起操作是通過調用schedule_timeout執行的。設備就緒后進程被通知繼續運 行，這時再次遍歷所有設備，以查找就緒設備。這一步因為兩次遍歷所有設備，時間復雜度也是O（n），這里面不包括等待時間。相關代碼在do_poll函數 中。

   3，將獲得的數據傳送到用戶空間并執行釋放內存和剝離等待隊列等善后工作，向用戶空間拷貝數據與剝離等待隊列等操作的的時間復雜度同樣是O（n），具體代碼包括do_sys_poll函數中調用do_poll后到結束的部分。

   EPOLL：

   接下來分析epoll，與poll/select不同，epoll不再是一個單獨的系統調用，而是由epoll_create/epoll_ctl/epoll_wait三個系統調用組成，后面將會看到這樣做的好處。

   先來看sys_epoll_create(epoll_create對應的內核函數），這個函數主要是做一些準備工作，比如創建數據結構，初始化數據并最終返回一個文件描述符（表示新創建的虛擬epoll文件），這個操作可以認為是一個固定時間的操作。

       epoll是做為一個虛擬文件系統來實現的，這樣做至少有以下兩個好處：

       1，可以在內核里維護一些信息，這些信息在多次epoll_wait間是保持的，比如所有受監控的文件描述符。

       2， epoll本身也可以被poll/epoll;

   具體epoll的虛擬文件系統的實現和性能分析無關，不再贅述。

   在sys_epoll_create中還能看到一個細節，就是epoll_create的參數size在現階段是沒有意義的，只要大于零就行。

   接著是sys_epoll_ctl(epoll_ctl對應的內核函數），需要明確的是每次調用sys_epoll_ctl只處理一個文件描述符，這里主 要描述當op為EPOLL_CTL_ADD時的執行過程，sys_epoll_ctl做一些安全性檢查后進入ep_insert，ep_insert里將 ep_poll_callback做為回掉函數加入設備的等待隊列（假定這時設備尚未就緒），由于每次poll_ctl只操作一個文件描述符，因此也可以 認為這是一個O(1)操作

       ep_poll_callback函數很關鍵，它在所等待的設備就緒后被系統回掉，執行兩個操作：

   1，將就緒設備加入就緒隊列，這一步避免了像poll那樣在設備就緒后再次輪詢所有設備找就緒者，降低了時間復雜度，由O（n）到O（1）;

   2，喚醒虛擬的epoll文件;

   最后是sys_epoll_wait，這里實際執行操作的是ep_poll函數。該函數等待將進程自身插入虛擬epoll文件的等待隊列，直到被喚醒（見 上面ep_poll_callback函數描述），最后執行ep_events_transfer將結果拷貝到用戶空間。由于只拷貝就緒設備信息，所以這 里的拷貝是一個O(1）操作。

   還有一個讓人關心的問題就是epoll對EPOLLET的處理，即邊沿觸發的處理，粗略看代碼就是把一部分水平觸發模式下內核做的工作交給用戶來處理，直覺上不會對性能有太大影響，感興趣的朋友歡迎討論。

   POLL/EPOLL對比：

   表面上poll的過程可以看作是由一次epoll_create/若干次epoll_ctl/一次epoll_wait/一次close等系統調用構成， 實際上epoll將poll分成若干部分實現的原因正是因為服務器軟件中使用poll的特點（比如Web服務器）：

   1，需要同時poll大量文件描述符;

   2，每次poll完成后就緒的文件描述符只占所有被poll的描述符的很少一部分。

   3，前后多次poll調用對文件描述符數組（ufds）的修改只是很小;

   傳統的poll函數相當于每次調用都重起爐灶，從用戶空間完整讀入ufds，完成后再次完全拷貝到用戶空間，另外每次poll都需要對所有設備做至少做一次加入和刪除等待隊列操作，這些都是低效的原因。

       epoll將以上情況都細化考慮，不需要每次都完整讀入輸出ufds，只需使用epoll_ctl調整其中一小部分，不需要每次 epoll_wait都執行一次加入刪除等待隊列操作，另外改進后的機制使的不必在某個設備就緒后搜索整個設備數組進行查找，這些都能提高效率。另外最明 顯的一點，從用戶的使用來說，使用epoll不必每次都輪詢所有返回結果已找出其中的就緒部分，O（n）變O（1），對性能也提高不少。

   此外這里還發現一點，是不是將epoll_ctl改成一次可以處理多個fd（像semctl那樣）會提高些許性能呢？特別是在假設系統調用比較耗時的基礎上。不過關于系統調用的耗時問題還會在以后分析。

   POLL/EPOLL測試數據對比：

   測試的環境：我寫了三段代碼來分別模擬服務器，活動的客戶端，僵死的客戶端，服務器運行于一個自編譯的標準2.6.11內核系統上，硬件為 PIII933，兩個客戶端各自運行在另外的PC上，這兩臺PC比服務器的硬件性能要好，主要是保證能輕易讓服務器滿載，三臺機器間使用一個100M交換 機連接。

   服務器接受并poll所有連接，如果有request到達則回復一個response，然后繼續poll。

   活動的客戶端（Active Client）模擬若干并發的活動連接，這些連接不間斷的發送請求接受回復。

   僵死的客戶端（zombie）模擬一些只連接但不發送請求的客戶端，其目的只是占用服務器的poll描述符資源。

       測試過程：保持10個并發活動連接，不斷的調整僵并發連接數，記錄在不同比例下使用poll與epoll的性能差別。僵死并發連接數根據比例分別是：0，10，20，40，80，160，320，640，1280，2560，5120，10240。

   下圖中橫軸表示僵死并發連接與活動并發連接之比，縱軸表示完成40000次請求回復所花費的時間，以秒為單位。紅色線條表示poll數據，綠色表示 epoll數據?？梢钥闯?，poll在所監控的文件描述符數量增加時，其耗時呈線性增長，而epoll則維持了一個平穩的狀態，幾乎不受描述符個數影響。

   在監控的所有客戶端都是活動時，poll的效率會略高于epoll（主要在原點附近，即僵死并發連接為0時，圖上不易看出來），究竟epoll實現比poll復雜，監控少量描述符并非它的長