Date: Thu, 15 Jun 2000 22:10:24 -0700 (PDT) From: Marc Slemko <marcs@znep.com> To: Daniel O'Connor <doconnor@gsoft.com.au> Cc: "Daniel C. Sobral" <dcs@newsguy.com>, Alfred Perlstein <alfred@FreeBSD.ORG>, Nate Williams <nate@yogotech.com>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern uipc_socket.c uipc_socket2.c src/sy Message-ID: <Pine.GSO.4.21.0006152204370.14352-100000@redfish> In-Reply-To: <XFMail.000616141108.doconnor@gsoft.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 16 Jun 2000, Daniel O'Connor wrote: > > The correct here is find _why_ there is a performance impact if this > > delay accept feature is not used, and fix _that_ instead. > > Well, my naivity abounds, but I would have thought it was because you do an > accept() which returns and then immediatly you go back to waiting on select(). Why should that be expensive? If thundering herd on accept() is a problem, add a wake_one. Which was done. If there is some similar problem elsewhere, fix it. If the select() interface is the problem, use poll() or something else that has an interface more suited to it. I just don't see what is that expensive about having to do an accept() then a select()-like call. In any case, if you are looking just for code that benchmarks well on simple static content, then the only answer is to stick the server (well, or a caching mini-server that only handles simple requests and punts anything it doesn't grok down to userland) in the kernel. Then you can come pretty darn close to saturating the bus (well, on other OSes; assuming FreeBSD has no other bottlenecks) before you run out of CPU. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.21.0006152204370.14352-100000>