• <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的細節(jié)的時候,發(fā)現(xiàn)一篇文章。 但不知文中說的是否有道理,望各位大大給個明確的答復(fù)。
            游戲服務(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 而導(dǎo)致非熱點 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 需要增加復(fù)雜的邏輯、花費更多的 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)用場景而定,不可一概而論。

            歡迎就此話題進行深入調(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 進行遍歷處理,如果處理邏輯比較復(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ù)  更多評論   

            国产Av激情久久无码天堂| 欧美成人免费观看久久| 99久久综合狠狠综合久久止| 国产99久久精品一区二区| 色噜噜狠狠先锋影音久久| 亚洲性久久久影院| 国产精品久久久久aaaa| 久久国产乱子伦精品免费午夜| 久久天天躁狠狠躁夜夜躁2014| 777米奇久久最新地址| 女同久久| 四虎国产精品免费久久5151 | 狠狠色伊人久久精品综合网 | 精品国产青草久久久久福利| 要久久爱在线免费观看| 蜜桃麻豆www久久| 色妞色综合久久夜夜| 久久综合色区| 亚洲国产精品久久久久| 久久99精品久久久久久hb无码| 中文字幕精品无码久久久久久3D日动漫 | 亚洲va中文字幕无码久久| 国产激情久久久久影院老熟女免费| 久久狠狠爱亚洲综合影院| 久久精品国产亚洲Aⅴ蜜臀色欲| 欧美亚洲色综久久精品国产| 久久中文字幕精品| 欧美亚洲另类久久综合婷婷| 久久免费小视频| 国产精品美女久久久| 欧美牲交A欧牲交aⅴ久久| 欧美国产成人久久精品| 最新久久免费视频| 尹人香蕉久久99天天拍| 久久一区二区免费播放| 国产2021久久精品| 国产综合精品久久亚洲| 国产精品久久久久久久久久免费| 久久免费视频观看| 久久嫩草影院免费看夜色| 日韩亚洲国产综合久久久|