• <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://m.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ù)  更多評論   

            国产精品激情综合久久| 亚洲另类欧美综合久久图片区| 国产99久久久国产精品小说| 伊人久久五月天| 久久av无码专区亚洲av桃花岛| 亚洲国产精品婷婷久久| yy6080久久| 久久精品国产亚洲一区二区| 亚洲欧美久久久久9999| 国产精品久久波多野结衣| 久久有码中文字幕| 久久偷看各类wc女厕嘘嘘| 国产午夜精品久久久久九九| 日本久久久久亚洲中字幕| 久久一本综合| 91精品国产91久久久久久| 国产精品久久久香蕉| 国产成人久久精品麻豆一区| 亚洲国产精品无码久久| 久久99九九国产免费看小说| 久久国产亚洲精品麻豆| 久久精品国产亚洲AV久| 亚洲精品成人久久久| 精品久久久久久久中文字幕| 久久水蜜桃亚洲av无码精品麻豆| 亚洲精品tv久久久久久久久久| 久久这里只有精品首页| 国产精品一区二区久久精品| 久久午夜伦鲁片免费无码| 伊人色综合久久天天人手人婷 | 97久久国产综合精品女不卡| 7国产欧美日韩综合天堂中文久久久久 | 伊人久久综在合线亚洲2019| 久久久亚洲欧洲日产国码aⅴ| 久久SE精品一区二区| 亚洲人AV永久一区二区三区久久 | 午夜精品久久久久久影视777 | 久久成人国产精品免费软件| 深夜久久AAAAA级毛片免费看 | 精品久久久久成人码免费动漫| 色婷婷综合久久久久中文字幕|