epoll為什麼這麼快,epoll的實現原理
阿新 • • 發佈:2019-01-28
以一個生活中的例子來解釋. 假設你在大學中讀書,要等待一個朋友來訪,而這個朋友只知道你在A號樓,但是不知道你具體住在哪裡,於是你們約好了在A號樓門口見面. 如果你使用的阻塞IO模型來處理這個問題,那麼你就只能一直守候在A號樓門口等待朋友的到來,在這段時間裡你不能做別的事情,不難知道,這種方式的效率是低下的. 進一步解釋select和epoll模型的差異. select版大媽做的是如下的事情:比如同學甲的朋友來了,select版大媽比較笨,她帶著朋友挨個房間進行查詢誰是同學甲,你等的朋友來了,於是在實際的程式碼中,select版大媽做的是以下的事情: int n = select(&readset,NULL,NULL,100); for (int i = 0; n > 0; ++i) { if (FD_ISSET(fdarray[i], &readset)) { do_something(fdarray[i]); --n; } }epoll版大媽就比較先進了,她記下了同學甲的資訊,比如說他的房間號,那麼等同學甲的朋友到來時,只需要告訴該朋友同學甲在哪個房間即可,不用自己親自帶著人滿大樓的找人了.於是epoll版大媽做的事情可以用如下的程式碼表示: n = epoll_wait(epfd,events,20,500); for(i=0;i<n;++i) { do_something(events[n]); } 在epoll中,關鍵的資料結構epoll_event定義如下: typedef union epoll_data { void *ptr; int fd; __uint32_t u32; __uint64_t u64; } epoll_data_t; struct epoll_event { __uint32_t events; /* Epoll events */ epoll_data_t data; /* User data variable */ }; 可以看到,epoll_data是一個union結構體,它就是epoll版大媽用於儲存同學資訊的結構體,它可以儲存很多型別的資訊:fd,指標,等等.有了這個結構體,epoll大媽可以不用吹灰之力就可以定位到同學甲. 別小看了這些效率的提高,在一個大規模併發的伺服器中,輪詢IO是最耗時間的操作之一.再回到那個例子中,如果每到來一個朋友樓管大媽都要全樓的查詢同學,那麼處理的效率必然就低下了,過不久樓底就有不少的人了. 對比最早給出的阻塞IO的處理模型, 可以看到採用了多路複用IO之後, 程式可以自由的進行自己除了IO操作之外的工作, 只有到IO狀態發生變化的時候由多路複用IO進行通知, 然後再採取相應的操作, 而不用一直阻塞等待IO狀態發生變化了. 從上面的分析也可以看出,epoll比select的提高實際上是一個用空間換時間思想的具體應用. 二、深入理解epoll的實現原理:開發高效能網路程式時,windows開發者們言必稱iocp,linux開發者們則言必稱epoll。大家都明白epoll是一種IO多路複用技術,可以非常高效的處理數以百萬計的socket控制代碼,比起以前的select和poll效率高大發了。我們用起epoll來都感覺挺爽,確實快,那麼,它到底為什麼可以高速處理這麼多併發連線呢? 先簡單回顧下如何使用C庫封裝的3個epoll系統呼叫吧。int epoll_create(int size); int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event); int epoll_wait(int epfd, struct epoll_event *events,int maxevents, int timeout); 使用起來很清晰,首先要呼叫epoll_create建立一個epoll物件。引數size是核心保證能夠正確處理的最大控制代碼數,多於這個最大數時核心可不保證效果。 epoll_ctl可以操作上面建立的epoll,例如,將剛建立的socket加入到epoll中讓其監控,或者把 epoll正在監控的某個socket控制代碼移出epoll,不再監控它等等。 epoll_wait在呼叫時,在給定的timeout時間內,當在監控的所有控制代碼中有事件發生時,就返回使用者態的程序。 從上面的呼叫方式就可以看到epoll比select/poll的優越之處:因為後者每次呼叫時都要傳遞你所要監控的所有socket給select/poll系統呼叫,這意味著需要將使用者態的socket列表copy到核心態,如果以萬計的控制代碼會導致每次都要copy幾十幾百KB的記憶體到核心態,非常低效。而我們呼叫epoll_wait時就相當於以往呼叫select/poll,但是這時卻不用傳遞socket控制代碼給核心,因為核心已經在epoll_ctl中拿到了要監控的控制代碼列表。 所以,實際上在你呼叫epoll_create後,核心就已經在核心態開始準備幫你儲存要監控的控制代碼了,每次呼叫epoll_ctl只是在往核心的資料結構裡塞入新的socket控制代碼。 在核心裡,一切皆檔案。所以,epoll向核心註冊了一個檔案系統,用於儲存上述的被監控socket。當你呼叫epoll_create時,就會在這個虛擬的epoll檔案系統裡建立一個file結點。當然這個file不是普通檔案,它只服務於epoll。epoll在被核心初始化時(作業系統啟動),同時會開闢出epoll自己的核心高速cache區,用於安置每一個我們想監控的socket,這些socket會以紅黑樹的形式儲存在核心cache裡,以支援快速的查詢、插入、刪除。這個核心高速cache區,就是建立連續的實體記憶體頁,然後在之上建立slab層,簡單的說,就是物理上分配好你想要的size的記憶體物件,每次使用時都是使用空閒的已分配好的物件。static int __init eventpoll_init(void) { ... ... /* Allocates slab cache used to allocate "struct epitem" items */ epi_cache = kmem_cache_create("eventpoll_epi", sizeof(struct epitem), 0, SLAB_HWCACHE_ALIGN|EPI_SLAB_DEBUG|SLAB_PANIC, NULL, NULL); /* Allocates slab cache used to allocate "struct eppoll_entry" */ pwq_cache = kmem_cache_create("eventpoll_pwq", sizeof(struct eppoll_entry), 0, EPI_SLAB_DEBUG|SLAB_PANIC, NULL, NULL); ... ... epoll的高效就在於,當我們呼叫epoll_ctl往裡塞入百萬個控制代碼時,epoll_wait仍然可以飛快的返回,並有效的將發生事件的控制代碼給我們使用者。這是由於我們在呼叫epoll_create時,核心除了幫我們在epoll檔案系統裡建了個file結點,在核心cache裡建了個紅黑樹用於儲存以後epoll_ctl傳來的socket外,還會再建立一個list連結串列,用於儲存準備就緒的事件,當epoll_wait呼叫時,僅僅觀察這個list連結串列裡有沒有資料即可。有資料就返回,沒有資料就sleep,等到timeout時間到後即使連結串列沒資料也返回。所以,epoll_wait非常高效。 那麼,這個準備就緒list連結串列是怎麼維護的呢?當我們執行epoll_ctl時,除了把socket放到epoll檔案系統裡file物件對應的紅黑樹上之外,還會給核心中斷處理程式註冊一個回撥函式,告訴核心,如果這個控制代碼的中斷到了,就把它放到準備就緒list連結串列裡。所以,當一個socket上有資料到了,核心在把網絡卡上的資料copy到核心中後就來把socket插入到準備就緒連結串列裡了。 如此,一顆紅黑樹,一張準備就緒控制代碼連結串列,少量的核心cache,就幫我們解決了大併發下的socket處理問題。執行epoll_create時,建立了紅黑樹和就緒連結串列,執行epoll_ctl時,如果增加socket控制代碼,則檢查在紅黑樹中是否存在,存在立即返回,不存在則新增到樹幹上,然後向核心註冊回撥函式,用於當中斷事件來臨時向準備就緒連結串列中插入資料。執行epoll_wait時立刻返回準備就緒連結串列裡的資料即可。 最後看看epoll獨有的兩種模式LT和ET。無論是LT和ET模式,都適用於以上所說的流程。區別是,LT模式下,只要一個控制代碼上的事件一次沒有處理完,會在以後呼叫epoll_wait時次次返回這個控制代碼,而ET模式僅在第一次返回。 這件事怎麼做到的呢?當一個socket控制代碼上有事件時,核心會把該控制代碼插入上面所說的準備就緒list連結串列,這時我們呼叫epoll_wait,會把準備就緒的socket拷貝到使用者態記憶體,然後清空準備就緒list連結串列,最後,epoll_wait幹了件事,就是檢查這些socket,如果不是ET模式(就是LT模式的控制代碼了),並且這些socket上確實有未處理的事件時,又把該控制代碼放回到剛剛清空的準備就緒連結串列了。所以,非ET的控制代碼,只要它上面還有事件,epoll_wait每次都會返回。而ET模式的控制代碼,除非有新中斷到,即使socket上的事件沒有處理完,也是不會次次從epoll_wait返回的。三、擴充套件閱讀(epoll與之前其他相關技術的比較): Linux提供了select、poll、epoll介面來實現IO複用,三者的原型如下所示,本文從引數、實現、效能等方面對三者進行對比。 int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout); int poll(struct pollfd *fds, nfds_t nfds, int timeout); int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout); select、poll、epoll_wait引數及實現對比 1. select的第一個引數nfds為fdset集合中最大描述符值加1,fdset是一個位數組,其大小限制為__FD_SETSIZE(1024),位陣列的每一位代表其對應的描述符是否需要被檢查。 select的第二三四個引數表示需要關注讀、寫、錯誤事件的檔案描述符位陣列,這些引數既是輸入引數也是輸出引數,可能會被核心修改用於標示哪些描述符上發生了關注的事件。所以每次呼叫select前都需要重新初始化fdset。 timeout引數為超時時間,該結構會被核心修改,其值為超時剩餘的時間。 select對應於核心中的sys_select呼叫,sys_select首先將第二三四個引數指向的fd_set拷貝到核心,然後對每個被SET的描述符呼叫進行poll,並記錄在臨時結果中(fdset),如果有事件發生,select會將臨時結果寫到使用者空間並返回;當輪詢一遍後沒有任何事件發生時,如果指定了超時時間,則select會睡眠到超時,睡眠結束後再進行一次輪詢,並將臨時結果寫到使用者空間,然後返回。 select返回後,需要逐一檢查關注的描述符是否被SET(事件是否發生)。 2. poll與select不同,通過一個pollfd陣列向核心傳遞需要關注的事件,故沒有描述符個數的限制,pollfd中的events欄位和revents分別用於標示關注的事件和發生的事件,故pollfd陣列只需要被初始化一次。 poll的實現機制與select類似,其對應核心中的sys_poll,只不過poll向核心傳遞pollfd陣列,然後對pollfd中的每個描述符進行poll,相比處理fdset來說,poll效率更高。 poll返回後,需要對pollfd中的每個元素檢查其revents值,來得指事件是否發生。 3. epoll通過epoll_create建立一個用於epoll輪詢的描述符,通過epoll_ctl新增/修改/刪除事件,通過epoll_wait檢查事件,epoll_wait的第二個引數用於存放結果。 epoll與select、poll不同,首先,其不用每次呼叫都向核心拷貝事件描述資訊,在第一次呼叫後,事件資訊就會與對應的epoll描述符關聯起來。另外epoll不是通過輪詢,而是通過在等待的描述符上註冊回撥函式,當事件發生時,回撥函式負責把發生的事件儲存在就緒事件連結串列中,最後寫到使用者空間。
轉自百度知道:http://zhidao.baidu.com/question/687563051895364284.html?qbl=relate_question_4
注:有些轉的內容,不一定正確,需要自己思考辨別。