On Thu, Mar 01, 2007 at 12:41:37PM +0100, Ingo Molnar (mingo@elte.hu) wrote:> > * Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:> > > I also changed client socket to nonblocking mode with the same result > > in epoll server. If you will find it broken, please send me corrected > > to test too.> > this line in evserver_kevent.c looks a bit fishy:> > err = recv(s, buf, 100, 0);> > because on the evserver_epoll.c side the following is done:> > err = recv(s, buf, 4096, 0);> > now, for 'ab', the request size is 76 bytes, so it should fit fine > functionality-wise. But, the TCP stack might decide differently of > whether to return with a partial packet depending on how much data is > requested. I dont know whether it actually makes a difference in the TCP > flow decisions, and whether it makes a performance difference in your > test, but safest would be to use 4096 in both cases.

Well, that would be quite strange - as far as I known linux networkstack (for which kevent was originally created to support network AIO),there should not be any difference.

> in general, please make sure the exact same system calls are done in the > client function. (except of course for the event queueing syscalls > themselves)

Yes, that should be done of course.I even have a plan to create the same binary for both, but have also inplans to turn some kevent optimization (mainly readiness-on-submit, whenrequested event (secv/send/anything) is ready immediately - keventsupports to return that event in the submission syscall withoutadditional overhead by reading it from ring or queue).