From owner-freebsd-hackers Sat Mar 7 21:42:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA04508 for freebsd-hackers-outgoing; Sat, 7 Mar 1998 21:42:27 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA04472 for ; Sat, 7 Mar 1998 21:42:16 -0800 (PST) (envelope-from marcs@znep.com) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id WAA06433; Sat, 7 Mar 1998 22:42:02 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id WAA03177; Sat, 7 Mar 1998 22:40:03 -0700 (MST) Date: Sat, 7 Mar 1998 22:40:02 -0700 (MST) From: Marc Slemko To: Mike Smith cc: hackers@FreeBSD.ORG Subject: Re: kernel wishlist for web server performance Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. > > The key features are: > > > > - it can transmit from an arbitrary start position and an > > arbitrary length. Sending starting from the current position > > is ok I guess, but requires a mutex to allow multiple > > threads to start it on the same descriptor at the same time and > > adds the overhead of a seek. > > - An AIO version of this system call would be very useful; > > NT can do this with its completion ports API. This is required > > to avoid having to dedicate a thread to a connection. > > 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. 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. > > > 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message