Linux2.6內核epoll介紹
[作者]：滕昱,2005/3/30,0.1版本
[版權聲明]：此文檔遵循GNU自由文檔許可證(GNU Free Documentation License).任何人可以自由複製,分發,修改,不過如果方便,請註明出處和作者:)
(1)導言：
首 先，我強烈建議大家閱讀Richard Stevens著作《TCP/IP Illustracted Volume 1,2,3》和《UNIX Network Programming Volume 1,2》。雖然他離開我們大家已經5年多了，但是他的書依然是進入網絡編程的最直接的道路。其中的3卷的《TCP/IP Illustracted》卷1是必讀－如果你不瞭解tcp協議各個選項的詳細定義，你就失去了優化程序重要的一個手段。卷2,3可以選讀一下。比如卷2 講解的是4.4BSD內核TCP/IP協議棧實現----這個版本的協議棧幾乎影響了現在所有的主流os，但是因爲年代久遠，內容不一定那麼vogue. 在這裏我多推薦一本《The Linux Networking Architecture--Design and Implementation of Network Protocols in the Linux Kernel》，以2.4內核講解Linux TCP/IP實現，相當不錯.作爲一個現實世界中的實現，很多時候你必須作很多權衡，這時候參考一個久經考驗的系統更有實際意義。舉個例子,linux內 核中sk_buff結構爲了追求速度和安全，犧牲了部分內存，所以在發送TCP包的時候，無論應用層數據多大,sk_buff最小也有272的字節.
其 實對於socket應用層程序來說，《UNIX Network Programming Volume 1》意義更大一點.2003年的時候，這本書出了最新的第3版本，不過主要還是修訂第2版本。其中第6章《I/O Multiplexing》是最重要的。Stevens給出了網絡IO的基本模型。在這裏最重要的莫過於select模型和Asynchronous I/O模型.從理論上說，AIO似乎是最高效的，你的IO操作可以立即返回，然後等待os告訴你IO操作完成。但是一直以來，如何實現就沒有一個完美的方 案。最著名的windows完成端口實現的AIO,實際上也是內部用線程池實現的罷了，最後的結果是IO有個線程池，你應用也需要一個線程池...... 很多文檔其實已經指出了這帶來的線程context-switch帶來的代價。
在linux 平臺上，關於網絡AIO一直是改動最多的地方，2.4的年代就有很多AIO內核patch,最著名的應該算是SGI那個。但是一直到2.6內核發佈，網絡 模塊的AIO一直沒有進入穩定內核版本(大部分都是使用用戶線程模擬方法，在使用了NPTL的linux上面其實和windows的完成端口基本上差不多 了)。2.6內核所支持的AIO特指磁盤的AIO---支持io_submit(),io_getevents()以及對Direct IO的支持(就是繞過VFS系統buffer直接寫硬盤，對於流服務器在內存平穩性上有相當幫助)。
所以，剩下的select模型基本上就 是我們在linux上面的唯一選擇，其實，如果加上no-block socket的配置，可以完成一個"僞"AIO的實現，只不過推動力在於你而不是os而已。不過傳統的select/poll函數有着一些無法忍受的缺 點，所以改進一直是2.4-2.5開發版本內核的任務，包括/dev/poll，realtime signal等等。最終，Davide Libenzi開發的epoll進入2.6內核成爲正式的解決方案
(2)epoll的優點
<1>支持一個進程打開大數目的socket描述符(FD)
select 最不能忍受的是一個進程所打開的FD是有一定限制的，由FD_SETSIZE設置，默認值是2048。對於那些需要支持的上萬連接數目的IM服務器來說顯 然太少了。這時候你一是可以選擇修改這個宏然後重新編譯內核，不過資料也同時指出這樣會帶來網絡效率的下降，二是可以選擇多進程的解決方案(傳統的 Apache方案)，不過雖然linux上面創建進程的代價比較小，但仍舊是不可忽視的，加上進程間數據同步遠比不上線程間同步的高效，所以也不是一種完 美的方案。不過 epoll則沒有這個限制，它所支持的FD上限是最大可以打開文件的數目，這個數字一般遠大於2048,舉個例子,在1GB內存的機器上大約是10萬左 右，具體數目可以cat /proc/sys/fs/file-max察看,一般來說這個數目和系統內存關係很大。
<2>IO效率不隨FD數目增加而線性下降
傳 統的select/poll另一個致命弱點就是當你擁有一個很大的socket集合，不過由於網絡延時，任一時間只有部分的socket是"活躍"的，但 是select/poll每次調用都會線性掃描全部的集合，導致效率呈現線性下降。但是epoll不存在這個問題，它只會對"活躍"的socket進行操 作---這是因爲在內核實現中epoll是根據每個fd上面的callback函數實現的。那麼，只有"活躍"的socket纔會主動的去調用 callback函數，其他idle狀態socket則不會，在這點上，epoll實現了一個"僞"AIO，因爲這時候推動力在os內核。在一些 benchmark中，如果所有的socket基本上都是活躍的---比如一個高速LAN環境，epoll並不比select/poll有什麼效率，相 反，如果過多使用epoll_ctl,效率相比還有稍微的下降。但是一旦使用idle connections模擬WAN環境,epoll的效率就遠在select/poll之上了。
<3>使用mmap加速內核與用戶空間的消息傳遞。
這 點實際上涉及到epoll的具體實現了。無論是select,poll還是epoll都需要內核把FD消息通知給用戶空間，如何避免不必要的內存拷貝就很 重要，在這點上，epoll是通過內核於用戶空間mmap同一塊內存實現的。而如果你想我一樣從2.5內核就關注epoll的話，一定不會忘記手工 mmap這一步的。
<4>內核微調
這一點其實不算epoll的優點了，而是整個linux平臺的優點。也許你可 以懷疑linux平臺，但是你無法迴避linux平臺賦予你微調內核的能力。比如，內核TCP/IP協議棧使用內存池管理sk_buff結構，那麼可以在 運行時期動態調整這個內存pool(skb_head_pool)的大小--- 通過echo XXXX>/proc/sys/net/core/hot_list_length完成。再比如listen函數的第2個參數(TCP完成3次握手 的數據包隊列長度)，也可以根據你平臺內存大小動態調整。更甚至在一個數據包面數目巨大但同時每個數據包本身大小卻很小的特殊系統上嘗試最新的NAPI網 卡驅動架構。
(3)epoll的使用
令人高興的是，2.6內核的epoll比其2.5開發版本的/dev/epoll簡潔了許多，所以，大部分情況下，強大的東西往往是簡單的。唯一有點麻煩是epoll有2種工作方式:LT和ET。
LT(level triggered)是缺省的工作方式，並且同時支持block和no-block socket.在這種做法中，內核告訴你一個文件描述符是否就緒了，然後你可以對這個就緒的fd進行IO操作。如果你不作任何操作，內核還是會繼續通知你 的，所以，這種模式編程出錯誤可能性要小一點。傳統的select/poll都是這種模型的代表．
ET (edge-triggered)是高速工作方式，只支持no-block socket。在這種模式下，當描述符從未就緒變爲就緒時，內核通過epoll告訴你。然後它會假設你知道文件描述符已經就緒，並且不會再爲那個文件描述 符發送更多的就緒通知，直到你做了某些操作導致那個文件描述符不再爲就緒狀態了(比如，你在發送，接收或者接收請求，或者發送接收的數據少於一定量時導致 了一個EWOULDBLOCK 錯誤）。但是請注意，如果一直不對這個fd作IO操作(從而導致它再次變成未就緒)，內核不會發送更多的通知(only once),不過在TCP協議中，ET模式的加速效用仍需要更多的benchmark確認。
epoll只有epoll_create,epoll_ctl,epoll_wait 3個系統調用，具體用法請參考http://www.xmailserver.org/linux-patches/nio-improve.html ，
在http://www.kegel.com/rn/也有一個完整的例子，大家一看就知道如何使用了
(4)Leader/follower模式線程pool實現，以及和epoll的配合
.....未完成，主要是要避免過多的epoll_ctl調用,以及嘗試使用EPOLLONESHOT加速......
(5)benchmark