We are going to run some in-house tests to see the throughput changes and the CPU usage changes w/ and w/out EPOLLET. We'll publicize the results when we're done w/ the tests. -Anirban
On Nov 24, 2009, at 8:53 AM, Anirban Kundu wrote: > Hi John, > Your point is well taken. > > Actually, there is a general mis-conception that putting EPOLLET > automatically makes the code faster. That is actually not true. The only > reason you benefit from EPOLLET, is because if you do miss reading the entire > data from the sock buffer, you dont constantly get pinged about something to > read. > > Theoretically, if your system is implemented correctly, as in read all the > data available from the network buffer (till you hit EAGAIN, or better yet > less than the amount you've asked to read), you really dont need to use > EPOLLET. > > There is a plan on removing EPOLLET from the system. One can achieve the same > system usage time, with and without EPOLLET. > > -Anirban > > On Nov 14, 2009, at 1:57 PM, John Plevyak wrote: > >> >> A couple things: >> >> 1. Current epoll seems to use EPOLLET in most cases (except for example the >> initial DNS connection). >> Is this required? It wasn't the case before and it isn't portable. Was it >> put in for performance? >> libev doesn't support EPOLLET because it isn't portable, and this >> requirement would prohibit an >> OSX port. >> >> 2. libevent is currently between the stable 1.X and a new 2.X-alpha with a >> new API. It doesn't seem sensible >> to either use the old API which is going away or use alpha code. >> >> I thinking of wrapping the current epoll calls and data structures with an >> API and try to make it as compatible >> as possible with libev and the new libevent 2.0 API. >> >> If I can get it in decent shape I'll circulate a patch. >> >> john >> >
