今天在查看EPOLLET和EPOLLLT的細節(jié)的時候，發(fā)現(xiàn)一篇文章。 但不知文中說的是否有道理，望各位大大給個明確的答復。
游戲服務器，我們用的是ET方式。
平時大家使用 epoll 時都知道其事件觸發(fā)模式有默認的 level-trigger 模式和通過 EPOLLET 啟用的 edge-trigger 模式兩種。從 epoll 發(fā)展歷史來看，它剛誕生時只有 edge-trigger 模式，后來因容易產(chǎn)生 race-cond 且不易被開發(fā)者理解，又增加了 level-trigger 模式并作為默認處理方式。
二者的差異在于 level-trigger 模式下只要某個 fd 處于 readable/writable 狀態(tài)，無論什么時候進行 epoll_wait 都會返回該 fd；而 edge-trigger 模式下只有某個 fd 從 unreadable 變?yōu)?readable 或從 unwritable 變?yōu)?writable 時，epoll_wait 才會返回該 fd。
通常的誤區(qū)是：level-trigger 模式在 epoll 池中存在大量 fd 時效率要顯著低于 edge-trigger 模式。
但從 kernel 代碼來看，edge-trigger/level-trigger 模式的處理邏輯幾乎完全相同，差別僅在于 level-trigger 模式在 event 發(fā)生時不會將其從 ready list 中移除，略為增大了 event 處理過程中 kernel space 中記錄數(shù)據(jù)的大小。
然而，edge-trigger 模式一定要配合 user app 中的 ready list 結構，以便收集已出現(xiàn) event 的 fd，再通過 round-robin 方式挨個處理，以此避免通信數(shù)據(jù)量很大時出現(xiàn)忙于處理熱點 fd 而導致非熱點 fd 餓死的現(xiàn)象。統(tǒng)觀 kernel 和 user space，由于 user app 中 ready list 的實現(xiàn)千奇百怪，不一定都經(jīng)過仔細的推敲優(yōu)化，因此 edge-trigger 的總內(nèi)存開銷往往還大于 level-trigger 的開銷。
一般號稱 edge-trigger 模式的優(yōu)勢在于能夠減少 epoll 相關系統(tǒng)調(diào)用，這話不假，但 user app 里可不是只有 epoll 相關系統(tǒng)調(diào)用吧？為了繞過餓死問題，edge-trigger 模式的 user app 要自行進行 read/write 循環(huán)處理，這其中增加的系統(tǒng)調(diào)用和減少的 epoll 系統(tǒng)調(diào)用加起來，有誰能說一定就能明顯地快起來呢？
實際上，epoll_wait 的效率是 O(ready fd num) 級別的，因此 edge-trigger 模式的真正優(yōu)勢在于減少了每次 epoll_wait 可能需要返回的 fd 數(shù)量，在并發(fā) event 數(shù)量極多的情況下能加快 epoll_wait 的處理速度，但別忘了這只是針對 epoll 體系自己而言的提升，與此同時 user app 需要增加復雜的邏輯、花費更多的 cpu/mem 與其配合工作，總體性能收益究竟如何？只有實際測量才知道，無法一概而論。不過，為了降低處理邏輯復雜度，常用的事件處理庫大部分都選擇了 level-trigger 模式（如 libevent、boost::asio等）
結論：
• epoll 的 edge-trigger 和 level-trigger 模式處理邏輯差異極小，性能測試結果表明常規(guī)應用場景 中二者性能差異可以忽略。
• 使用 edge-trigger 的 user app 比使用 level-trigger 的邏輯復雜，出錯概率更高。
• edge-trigger 和 level-trigger 的性能差異主要在于 epoll_wait 系統(tǒng)調(diào)用的處理速度，是否是 user app 的性能瓶頸需要視應用場景而定，不可一概而論。
歡迎就此話題進行深入調(diào)研、討論！
參考資料：
• linux kernel source：fs/eventpoll.c
• “Comparing and Evaluating epoll, select, and poll Event
Mechanisms”：http://bcr2.uwaterloo.ca/~brecht/papers/getpaper.php?file=ols-2004.pdf
• “Edge-triggered interfaces are too difficult?”：http://lwn.net/Articles/25137/
By QingWu