在man epoll中的Notes說到：
EPOLL事件分發(fā)系統(tǒng)可以運轉(zhuǎn)在兩種模式下：
?? Edge Triggered (ET)
?? Level Triggered (LT)
接下來說明ET, LT這兩種事件分發(fā)機制的不同。我們假定一個環(huán)境：
1. 我們已經(jīng)把一個用來從管道中讀取數(shù)據(jù)的文件句柄(RFD)添加到epoll描述符
2. 這個時候從管道的另一端被寫入了2KB的數(shù)據(jù)
3. 調(diào)用epoll_wait(2)，并且它會返回RFD，說明它已經(jīng)準備好讀取操作
4. 然后我們讀取了1KB的數(shù)據(jù)
5. 調(diào)用epoll_wait(2)......
Edge Triggered 工作模式：
如果我們在第1步將RFD添加到epoll描述符的時候使用了EPOLLET標志，那么在第5步調(diào)用epoll_wait(2)之后將有可能會掛起，因為剩余的數(shù)據(jù)還存在于文件的輸入緩沖區(qū)內(nèi)，而且數(shù)據(jù)發(fā)出端還在等待一個針對已經(jīng)發(fā)出數(shù)據(jù)的反饋信息。只有在監(jiān)視的文件句柄上發(fā)生了某個事件的時候 ET 工作模式才會匯報事件。因此在第5步的時候，調(diào)用者可能會放棄等待仍在存在于文件輸入緩沖區(qū)內(nèi)的剩余數(shù)據(jù)。在上面的例子中，會有一個事件產(chǎn)生在RFD句柄上，因為在第2步執(zhí)行了一個寫操作，然后，事件將會在第3步被銷毀。因為第4步的讀取操作沒有讀空文件輸入緩沖區(qū)內(nèi)的數(shù)據(jù)，因此我們在第5步調(diào)用epoll_wait(2)完成后，是否掛起是不確定的。epoll工作在ET模式的時候，必須使用非阻塞套接口，以避免由于一個文件句柄的阻塞讀/阻塞寫操作把處理多個文件描述符的任務餓死。最好以下面的方式調(diào)用ET模式的epoll接口，在后面會介紹避免可能的缺陷。
?? i??? 基于非阻塞文件句柄
?? ii?? 只有當read(2)或者write(2)返回EAGAIN時才需要掛起，等待
Level Triggered 工作模式
相反的，以LT方式調(diào)用epoll接口的時候，它就相當于一個速度比較快的poll(2)，并且無論后面的數(shù)據(jù)是否被使用，因此他們具有同樣的職能。因為即使使用ET模式的epoll，在收到多個chunk的數(shù)據(jù)的時候仍然會產(chǎn)生多個事件。調(diào)用者可以設定EPOLLONESHOT標志，在epoll_wait(2)收到事件后epoll會與事件關聯(lián)的文件句柄從epoll描述符中禁止掉。因此當EPOLLONESHOT設定后，使用帶有EPOLL_CTL_MOD標志的epoll_ctl(2)處理文件句柄就成為調(diào)用者必須作的事情。
以上翻譯自man epoll.
然后詳細解釋ET, LT:
LT(level triggered)是缺省的工作方式，并且同時支持block和no-block socket.在這種做法中，內(nèi)核告訴你一個文件描述符是否就緒了，然后你可以對這個就緒的fd進行IO操作。如果你不作任何操作，內(nèi)核還是會繼續(xù)通知你的，所以，這種模式編程出錯誤可能性要小一點。傳統(tǒng)的select/poll都是這種模型的代表．
ET(edge-triggered)是高速工作方式，只支持no-block socket。在這種模式下，當描述符從未就緒變?yōu)榫途w時，內(nèi)核通過epoll告訴你。然后它會假設你知道文件描述符已經(jīng)就緒，并且不會再為那個文件描述符發(fā)送更多的就緒通知，直到你做了某些操作導致那個文件描述符不再為就緒狀態(tài)了(比如，你在發(fā)送，接收或者接收請求，或者發(fā)送接收的數(shù)據(jù)少于一定量時導致了一個EWOULDBLOCK 錯誤）。但是請注意，如果一直不對這個fd作IO操作(從而導致它再次變成未就緒)，內(nèi)核不會發(fā)送更多的通知(only once),不過在TCP協(xié)議中，ET模式的加速效用仍需要更多的benchmark確認。
在許多測試中我們會看到如果沒有大量的idle-connection或者dead-connection，epoll的效率并不會比select/poll高很多，但是當我們遇到大量的idle-connection(例如WAN環(huán)境中存在大量的慢速連接)，就會發(fā)現(xiàn)epoll的效率大大高于select/poll。?
其他細節(jié):
1、為什么select是落后的？
首先，在Linux內(nèi)核中，select所用到的FD_SET是有限的，即內(nèi)核中有個參數(shù)__FD_SETSIZE定義了每個FD_SET的句柄個數(shù)，在我用的2.6.15-25-386內(nèi)核中，該值是1024，搜索內(nèi)核源代碼得到：
include/linux/posix_types.h:#define __FD_SETSIZE??????? 1024
也就是說，如果想要同時檢測1025個句柄的可讀狀態(tài)是不可能用select實現(xiàn)的。或者同時檢測1025個句柄的可寫狀態(tài)也是不可能的。
其次，內(nèi)核中實現(xiàn)select是用輪詢方法，即每次檢測都會遍歷所有FD_SET中的句柄，顯然，select函數(shù)執(zhí)行時間與FD_SET中的句柄個數(shù)有一個比例關系，即select要檢測的句柄數(shù)越多就會越費時。
當然，在前文中我并沒有提及poll方法，事實上用select的朋友一定也試過poll，我個人覺得select和poll大同小異，個人偏好于用select而已。
、2.6內(nèi)核中提高I/O性能的epoll
?
epoll是什么？按照man手冊的說法：是為處理大批量句柄而作了改進的poll。要使用epoll只需要這三個系統(tǒng)調(diào)用：epoll_create(2)， epoll_ctl(2)， epoll_wait(2)。
當然，這不是2.6內(nèi)核才有的，它是在2.5.44內(nèi)核中被引進的(epoll(4) is a new API introduced in Linux kernel 2.5.44)
(1)導言：
?
首先，我強烈建議大家閱讀Richard Stevens著作《TCP/IP Illustracted Volume 1,2,3》和《UNIX Network Programming Volume 1,2》。雖然他離開我們大家已經(jīng)5年多了，但是他的書依然是進入網(wǎng)絡編程的最直接的道路。其中的3卷的《TCP/IP Illustracted》卷1是必讀－如果你不了解tcp協(xié)議各個選項的詳細定義，你就失去了優(yōu)化程序重要的一個手段。卷2,3可以選讀一下。比如卷2 講解的是4.4BSD內(nèi)核TCP/IP協(xié)議棧實現(xiàn)----這個版本的協(xié)議棧幾乎影響了現(xiàn)在所有的主流os，但是因為年代久遠，內(nèi)容不一定那么vogue. 在這里我多推薦一本《The Linux Networking Architecture--Design and Implementation of Network Protocols in the Linux Kernel》，以2.4內(nèi)核講解Linux TCP/IP實現(xiàn)，相當不錯.作為一個現(xiàn)實世界中的實現(xiàn)，很多時候你必須作很多權衡，這時候參考一個久經(jīng)考驗的系統(tǒng)更有實際意義。舉個例子,linux內(nèi)核中sk_buff結(jié)構為了追求速度和安全，犧牲了部分內(nèi)存，所以在發(fā)送TCP包的時候，無論應用層數(shù)據(jù)多大,sk_buff最小也有272的字節(jié).
?
其實對于socket應用層程序來說，《UNIX Network Programming Volume 1》意義更大一點.2003年的時候，這本書出了最新的第3版本，不過主要還是修訂第2版本。其中第6章《I/O Multiplexing》是最重要的。Stevens給出了網(wǎng)絡IO的基本模型。在這里最重要的莫過于select模型和Asynchronous I/O模型.從理論上說，AIO似乎是最高效的，你的IO操作可以立即返回，然后等待os告訴你IO操作完成。但是一直以來，如何實現(xiàn)就沒有一個完美的方案。最著名的windows完成端口實現(xiàn)的AIO,實際上也是內(nèi)部用線程池實現(xiàn)的罷了，最后的結(jié)果是IO有個線程池，你應用也需要一個線程池...... 很多文檔其實已經(jīng)指出了這帶來的線程context-switch帶來的代價。
?
在linux 平臺上，關于網(wǎng)絡AIO一直是改動最多的地方，2.4的年代就有很多AIO內(nèi)核patch,最著名的應該算是SGI那個。但是一直到2.6內(nèi)核發(fā)布，網(wǎng)絡模塊的AIO一直沒有進入穩(wěn)定內(nèi)核版本(大部分都是使用用戶線程模擬方法，在使用了NPTL的linux上面其實和windows的完成端口基本上差不多了)。2.6內(nèi)核所支持的AIO特指磁盤的AIO---支持io_submit(),io_getevents()以及對Direct IO的支持(就是繞過VFS系統(tǒng)buffer直接寫硬盤，對于流服務器在內(nèi)存平穩(wěn)性上有相當幫助)。
?
所以，剩下的select模型基本上就是我們在linux上面的唯一選擇，其實，如果加上no-block socket的配置，可以完成一個"偽"AIO的實現(xiàn)，只不過推動力在于你而不是os而已。不過傳統(tǒng)的select/poll函數(shù)有著一些無法忍受的缺點，所以改進一直是2.4-2.5開發(fā)版本內(nèi)核的任務，包括/dev/poll，realtime signal等等。最終，Davide Libenzi開發(fā)的epoll進入2.6內(nèi)核成為正式的解決方案
?
(2)epoll的優(yōu)點
?
<1>支持一個進程打開大數(shù)目的socket描述符(FD)
?
select 最不能忍受的是一個進程所打開的FD是有一定限制的，由FD_SETSIZE設置，默認值是2048。對于那些需要支持的上萬連接數(shù)目的IM服務器來說顯然太少了。這時候你一是可以選擇修改這個宏然后重新編譯內(nèi)核，不過資料也同時指出這樣會帶來網(wǎng)絡效率的下降，二是可以選擇多進程的解決方案(傳統(tǒng)的Apache方案)，不過雖然linux上面創(chuàng)建進程的代價比較小，但仍舊是不可忽視的，加上進程間數(shù)據(jù)同步遠比不上線程間同步的高效，所以也不是一種完美的方案。不過 epoll則沒有這個限制，它所支持的FD上限是最大可以打開文件的數(shù)目，這個數(shù)字一般遠大于2048,舉個例子,在1GB內(nèi)存的機器上大約是10萬左右，具體數(shù)目可以cat /proc/sys/fs/file-max察看,一般來說這個數(shù)目和系統(tǒng)內(nèi)存關系很大。
?
<2>IO效率不隨FD數(shù)目增加而線性下降
?
傳統(tǒng)的select/poll另一個致命弱點就是當你擁有一個很大的socket集合，不過由于網(wǎng)絡延時，任一時間只有部分的socket是"活躍"的，但是select/poll每次調(diào)用都會線性掃描全部的集合，導致效率呈現(xiàn)線性下降。但是epoll不存在這個問題，它只會對"活躍"的socket進行操作---這是因為在內(nèi)核實現(xiàn)中epoll是根據(jù)每個fd上面的callback函數(shù)實現(xiàn)的。那么，只有"活躍"的socket才會主動的去調(diào)用 callback函數(shù)，其他idle狀態(tài)socket則不會，在這點上，epoll實現(xiàn)了一個"偽"AIO，因為這時候推動力在os內(nèi)核。在一些 benchmark中，如果所有的socket基本上都是活躍的---比如一個高速LAN環(huán)境，epoll并不比select/poll有什么效率，相反，如果過多使用epoll_ctl,效率相比還有稍微的下降。但是一旦使用idle connections模擬WAN環(huán)境,epoll的效率就遠在select/poll之上了。
?
<3>使用mmap加速內(nèi)核與用戶空間的消息傳遞。
?
這點實際上涉及到epoll的具體實現(xiàn)了。無論是select,poll還是epoll都需要內(nèi)核把FD消息通知給用戶空間，如何避免不必要的內(nèi)存拷貝就很重要，在這點上，epoll是通過內(nèi)核于用戶空間mmap同一塊內(nèi)存實現(xiàn)的。而如果你想我一樣從2.5內(nèi)核就關注epoll的話，一定不會忘記手工 mmap這一步的。
?
<4>內(nèi)核微調(diào)
?
這一點其實不算epoll的優(yōu)點了，而是整個linux平臺的優(yōu)點。也許你可以懷疑linux平臺，但是你無法回避linux平臺賦予你微調(diào)內(nèi)核的能力。比如，內(nèi)核TCP/IP協(xié)議棧使用內(nèi)存池管理sk_buff結(jié)構，那么可以在運行時期動態(tài)調(diào)整這個內(nèi)存pool(skb_head_pool)的大小--- 通過echo XXXX>/proc/sys/net/core/hot_list_length完成。再比如listen函數(shù)的第2個參數(shù)(TCP完成3次握手的數(shù)據(jù)包隊列長度)，也可以根據(jù)你平臺內(nèi)存大小動態(tài)調(diào)整。更甚至在一個數(shù)據(jù)包面數(shù)目巨大但同時每個數(shù)據(jù)包本身大小卻很小的特殊系統(tǒng)上嘗試最新的NAPI網(wǎng)卡驅(qū)動架構。
?
(3)epoll的使用
?
令人高興的是，2.6內(nèi)核的epoll比其2.5開發(fā)版本的/dev/epoll簡潔了許多，所以，大部分情況下，強大的東西往往是簡單的。唯一有點麻煩是epoll有2種工作方式:LT和ET。
?
LT(level triggered)是缺省的工作方式，并且同時支持block和no-block socket.在這種做法中，內(nèi)核告訴你一個文件描述符是否就緒了，然后你可以對這個就緒的fd進行IO操作。如果你不作任何操作，內(nèi)核還是會繼續(xù)通知你的，所以，這種模式編程出錯誤可能性要小一點。傳統(tǒng)的select/poll都是這種模型的代表．
?
ET (edge-triggered)是高速工作方式，只支持no-block socket。在這種模式下，當描述符從未就緒變?yōu)榫途w時，內(nèi)核通過epoll告訴你。然后它會假設你知道文件描述符已經(jīng)就緒，并且不會再為那個文件描述符發(fā)送更多的就緒通知，直到你做了某些操作導致那個文件描述符不再為就緒狀態(tài)了(比如，你在發(fā)送，接收或者接收請求，或者發(fā)送接收的數(shù)據(jù)少于一定量時導致了一個EWOULDBLOCK 錯誤）。但是請注意，如果一直不對這個fd作IO操作(從而導致它再次變成未就緒)，內(nèi)核不會發(fā)送更多的通知(only once),不過在TCP協(xié)議中，ET模式的加速效用仍需要更多的benchmark確認。
?
本文來自CSDN博客，轉(zhuǎn)載請標明出處：http://blog.csdn.net/umbrella1984/archive/2006/10/06/1322890.aspx