From owner-freebsd-hackers Sat Mar 7 21:56:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA07363 for freebsd-hackers-outgoing; Sat, 7 Mar 1998 21:56:45 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA07358 for ; Sat, 7 Mar 1998 21:56:42 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id VAA08633; Sat, 7 Mar 1998 21:54:12 -0800 (PST) Message-Id: <199803080554.VAA08633@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Marc Slemko cc: Mike Smith , hackers@FreeBSD.ORG Subject: Re: kernel wishlist for web server performance In-reply-to: Your message of "Sat, 07 Mar 1998 22:40:02 MST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 07 Mar 1998 21:54:12 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Sat, 7 Mar 1998, Mike Smith wrote: > > > > A sendfile() (eg. HPUX 11.x) or TransmitFile (eg. WinNT) system call. ... > > How does this differ from mmap/AIOwrite in terms of what it actually > > achieves? > > Because you more easily do copy avoidance. The idea is that it will copy > data out of the buffer cache to the network without any data copies in the > middle, ie. to mbufs. Trying to implement this using traditional calls is > possible, but can get ugly and involves some tradeoffs. With a > sendfile(), the memory for the socket buffer goes away and the kernel can > essentially copy data directly from the buffer cache. > > Combine that with a file handle cache of frequently accessed files in the > server, and you no longer have to open and close files, and sending the > response is a single syscall that goes from the buffer cache to the > network. This smacks of being a grubby hack to avoid dealing with performance problems in the host operating system. > While you can easily make a wrapper that has the same external view in > user space there is no point because performance sucks. Also, many > systems have troubles with large write()s so you have to split them up. Well, FreeBSD obviously isn't "most systems". I'm curious as to whether performance in that case "sucks" too - what you describe is basically what an FTP server does, and wcarchive should give you some idea as to how well that works already. I appreciate the conceptual niceness of what you're describing, but I guess I'm not convinced that something like that would be worth the cruft and effort involved. To my mind, the biggest win is in not having to do anything about the write until it has completed (or failed), and for this AIO is adequate. Perhaps that would be better worded differently: Do you have specific test results that indicate that, on FreeBSD, it is unacceptably inefficient to mmap/AIOwrite? Or is it the case that on some platforms it is, and you want to keep Apache as simple as possible in this regard (ie. have specific HTTP-transmit-file system calls everywhere)? > > > An efficient poll(). > > > > What's inefficient about the current poll()? > > I have no idea; haven't looked. All I mean is a real poll that doesn't > just hack on top of select but is implemented the logical way for poll to > be done. And what's that? The poll(2) implementation in 3.0 is based on the NetBSD poll(2), AFAIR. It certainly has different internal semantics, although the two do achieve basically the same thing. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message