• <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>

            麒麟子

            ~~

            導(dǎo)航

            <2025年5月>
            27282930123
            45678910
            11121314151617
            18192021222324
            25262728293031
            1234567

            統(tǒng)計

            常用鏈接

            留言簿(12)

            隨筆分類

            隨筆檔案

            Friends

            WebSites

            積分與排名

            最新隨筆

            最新評論

            閱讀排行榜

            評論排行榜

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

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

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


            平時大家使用 epoll 時都知道其事件觸發(fā)模式有默認(rèn)的 level-trigger 模式和通過 EPOLLET 啟用的 edge-trigger 模式兩種。從 epoll 發(fā)展歷史來看,它剛誕生時只有 edge-trigger 模式,后來因容易產(chǎn)生 race-cond 且不易被開發(fā)者理解,又增加了 level-trigger 模式并作為默認(rèn)處理方式。

            二者的差異在于 level-trigger 模式下只要某個 fd 處于 readable/writable 狀態(tài),無論什么時候進(jìn)行 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 而導(dǎo)致非熱點 fd 餓死的現(xiàn)象。統(tǒng)觀 kernel 和 user space,由于 user app 中 ready list 的實現(xiàn)千奇百怪,不一定都經(jīng)過仔細(xì)的推敲優(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 要自行進(jìn)行 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 需要增加復(fù)雜的邏輯、花費(fèi)更多的 cpu/mem 與其配合工作,總體性能收益究竟如何?只有實際測量才知道,無法一概而論。不過,為了降低處理邏輯復(fù)雜度,常用的事件處理庫大部分都選擇了 level-trigger 模式(如 libevent、boost::asio等)

            結(jié)論:
            • epoll 的 edge-trigger 和 level-trigger 模式處理邏輯差異極小,性能測試結(jié)果表明常規(guī)應(yīng)用場景 中二者性能差異可以忽略。
            • 使用 edge-trigger 的 user app 比使用 level-trigger 的邏輯復(fù)雜,出錯概率更高。
            • edge-trigger 和 level-trigger 的性能差異主要在于 epoll_wait 系統(tǒng)調(diào)用的處理速度,是否是 user app 的性能瓶頸需要視應(yī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


            posted on 2013-02-25 13:05 麒麟子 閱讀(7776) 評論(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)用都會馬上有事件返回,導(dǎo)致不必要的CPU空耗。
            2、在網(wǎng)絡(luò)IO比較大,尤其是連接數(shù)比較多的時候,每次epoll_wait調(diào)用時LT模式肯定比ET模式多,因為之后需要對ready list 進(jìn)行遍歷處理,如果處理邏輯比較復(fù)雜,或者之前反饋的事件數(shù)LT比ET多很多的話,這時候效率差異就比較明顯了。

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

            久久人妻无码中文字幕| 97久久国产露脸精品国产| 欧美午夜精品久久久久久浪潮| 久久久久国产一区二区三区| 国产69精品久久久久9999APGF | 精品熟女少妇AV免费久久| 精品国产乱码久久久久久1区2区 | 久久狠狠高潮亚洲精品| 久久精品亚洲男人的天堂| 五月丁香综合激情六月久久| 99久久成人国产精品免费| 亚洲中文字幕伊人久久无码| 香港aa三级久久三级| 狠狠色婷婷久久一区二区 | 久久99久久99精品免视看动漫| 91精品国产91久久久久久青草 | 国产日韩欧美久久| 久久久久成人精品无码中文字幕| 人人狠狠综合88综合久久| 亚洲综合久久综合激情久久 | 国产精品免费久久久久影院| 中文字幕无码久久久| 精品无码久久久久久国产| 久久人人爽人人爽人人AV东京热| 久久久午夜精品| 狠狠人妻久久久久久综合蜜桃| 999久久久无码国产精品| 色综合久久久久无码专区| 国内精品久久久久久麻豆| 久久九九亚洲精品| 国产婷婷成人久久Av免费高清 | 精品久久久久久| 久久av无码专区亚洲av桃花岛| 一本色道久久综合狠狠躁| 久久精品极品盛宴观看| 伊人久久大香线蕉AV一区二区| 久久久这里有精品中文字幕| 国产综合免费精品久久久| 久久国产午夜精品一区二区三区| 亚洲精品高清国产一久久| 狠狠久久综合伊人不卡|