• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            麒麟子

            ~~

            導航

            <2025年8月>
            272829303112
            3456789
            10111213141516
            17181920212223
            24252627282930
            31123456

            統(tǒng)計

            常用鏈接

            留言簿(12)

            隨筆分類

            隨筆檔案

            Friends

            WebSites

            積分與排名

            最新隨筆

            最新評論

            閱讀排行榜

            評論排行榜

            請教大家一個關(guān)于EPOLLET和EPOLLLT的問題

            今天在查看EPOLLET和EPOLLLT的細節(jié)的時候,發(fā)現(xiàn)一篇文章。 但不知文中說的是否有道理,望各位大大給個明確的答復。
            游戲服務(wù)器,我們用的是ET方式。

            剖析 epoll ET/LT 觸發(fā)方式的性能差異誤解(定性分析)


            平時大家使用 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 結(jié)構(gòu),以便收集已出現(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 相關(guān)系統(tǒng)調(diào)用,這話不假,但 user app 里可不是只有 epoll 相關(guān)系統(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等)

            結(jié)論:
            • epoll 的 edge-trigger 和 level-trigger 模式處理邏輯差異極小,性能測試結(jié)果表明常規(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


            posted on 2013-02-25 13:05 麒麟子 閱讀(7794) 評論(1)  編輯 收藏 引用 所屬分類: Programming

            評論

            # re: 請教大家一個關(guān)于EPOLLET和EPOLLLT的問題 2013-02-26 16:14 peakflys

            其實這個問題我之前在一篇blog里已經(jīng)討論過(http://www.shnenglu.com/peakflys/archive/2012/08/26/188344.aspx)
            我現(xiàn)在的結(jié)論是:ET模式在網(wǎng)絡(luò)層方面的效率確實比LT要高。
            主要表現(xiàn)在:
            1、網(wǎng)絡(luò)IO比較小時,send buffer表現(xiàn)為一直可寫,如果網(wǎng)絡(luò)主循環(huán)沒有延時操作的話,epoll_wait每次調(diào)用都會馬上有事件返回,導致不必要的CPU空耗。
            2、在網(wǎng)絡(luò)IO比較大,尤其是連接數(shù)比較多的時候,每次epoll_wait調(diào)用時LT模式肯定比ET模式多,因為之后需要對ready list 進行遍歷處理,如果處理邏輯比較復雜,或者之前反饋的事件數(shù)LT比ET多很多的話,這時候效率差異就比較明顯了。

            還是那句話,ET模式在網(wǎng)絡(luò)主循環(huán)處理的效率肯定比LT模式要高,至于高多少,視具體應用和具體實現(xiàn)。當然ET模式的代價就是增加了網(wǎng)絡(luò)層的邏輯處理復雜度,必須保證時刻知道fd當前的狀態(tài)。  回復  更多評論   

            久久国产一片免费观看| 国产精品禁18久久久夂久| 久久久99精品成人片中文字幕 | 亚洲色欲久久久综合网东京热| 偷窥少妇久久久久久久久| 亚洲午夜久久久久久久久久| 久久久久亚洲AV片无码下载蜜桃 | 精品多毛少妇人妻AV免费久久| 青青热久久国产久精品| 久久99国产精品尤物| 久久国产视屏| 国产亚洲婷婷香蕉久久精品| 青青草国产97免久久费观看| 麻豆AV一区二区三区久久| 国内精品伊人久久久久网站| 欧洲成人午夜精品无码区久久 | 亚洲午夜福利精品久久| 久久久国产精品亚洲一区| 久久伊人色| 91精品观看91久久久久久| 久久亚洲精品国产精品婷婷| 色综合久久88色综合天天| 久久久老熟女一区二区三区| 亚洲人成电影网站久久| 久久久网中文字幕| 久久99国产精品一区二区| 久久这里只有精品18| 久久九九兔免费精品6| 精品久久人人妻人人做精品| 国产精品美女久久久久久2018| 久久综合偷偷噜噜噜色| 久久国产精品无码网站| 久久国产精品久久| 久久综合给合久久狠狠狠97色| 超级97碰碰碰碰久久久久最新| 精品久久久久久无码免费| 国产精品狼人久久久久影院 | 久久久久亚洲AV无码专区网站| 一级做a爰片久久毛片人呢| 国产精品一区二区久久精品| 久久ww精品w免费人成|