Date: Sun, 8 Mar 1998 13:04:54 -0700 (MST) From: Marc Slemko <marcs@znep.com> To: Chris Csanady <ccsanady@friley585.res.iastate.edu> Cc: hackers@FreeBSD.ORG Subject: Re: kernel wishlist for web server performance Message-ID: <Pine.BSF.3.95.980308125648.2799d-100000@alive.znep.com> In-Reply-To: <199803081954.NAA03166@friley585.res.iastate.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 8 Mar 1998, Chris Csanady wrote: > >To avoid that copy, you have two choices. First, you can play around with > >copy avoidance for mmap() then send() or write(). This can be done with > >COW, or page flipping. See the HP paper for more details on this > >approach. Doing it this way is really an ugly hack and there are numerous > >difficulties that crop up, making it less than desirable. > > Where is page flipping needed here? There is no data coming from user > space with the mmap+aiosend.. If you are sending, you need COW to avoid the copy. If you are receiving (which I didn't really talk about, which SendFile() doesn't help, and which I don't care much about for web server performance, so you are correct that it doesn't apply for the send case) you can use page flipping to make the data appear in the application buffer without copying. Note that both of these require the app to take care with how it dirties the buffers afterwards. eg. an application has to be careful not to reuse the send buffer until after the transport layer is done with it. This is _NOT_ typical of most TCP servers. If it doesn't do it right, you can end up with more overhead from trying to do copy avoidance than just not doing it. This is one reason why HPUX requires you to explicitly enable the option with setsockopt() if your application wants to use it and why sendfile() is conceptually cleaner, both in userspace and in the kernel. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.980308125648.2799d-100000>