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