From owner-freebsd-arch@FreeBSD.ORG Tue May 27 01:25:45 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9594237B401 for ; Tue, 27 May 2003 01:25:45 -0700 (PDT) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9063943F3F for ; Tue, 27 May 2003 01:25:44 -0700 (PDT) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id h4R8PhmF013149; Tue, 27 May 2003 12:25:43 +0400 (MSD) Date: Tue, 27 May 2003 12:25:43 +0400 (MSD) From: Igor Sysoev X-Sender: is@is To: Terry Lambert In-Reply-To: <3ED2AF18.F5EB4FA5@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: sendfile(2) SF_NOPUSH flag proposal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2003 08:25:45 -0000 On Mon, 26 May 2003, Terry Lambert wrote: > Igor Sysoev wrote: > > sendfile(2) now has two drawbacks: > > Only two? ;^). No, I know some other drawbacks but I do not see now the ways to resolve them. > > So here is a proposal. We can introduce a sendfile(2) flag, i.e. SF_NOPUSH > > that will turn TF_NOPUSH on before the sending and turn it off just > > before return. It allows to save two syscalls on each sendfile() call > > and it's especially useful with non-blocking sockets - they can cause many > > sendfile() calls. > > I don't see this as being terrifically useful; small files > should probably just be mapped and written; the copy expense > is still there for the headers and trailers, no matter what, > and the file size itself is very small overhead, relatively > speaking, for files small enough for this to be an issue. FreeBSD 4.x has no zero_copy(9) so mmap()ed files would be copied. sendfile() allows to avoid this copy. By the way what do you call by small files ? 4K, 30K or 100K ? > I also think your headers and trailers are very small, if > they are fitting with the file contents in a single packet. > I think this is atypical. If I ask Google: ---- HEAD /images/hp0.gif HTTP/1.0 Host: www.google.com ---- it will return me 230 bytes: ---- HTTP/1.0 200 OK Connection: Keep-Alive Date: Tue, 27 May 2003 08:10:59 GMT Content-Type: image/gif Last-Modified: Tue, 22 Apr 2003 22:18:49 GMT Expires: Sun, 17 Jan 2038 19:14:07 GMT Content-length: 4277 Server: GWS/2.0 ---- and it's the typical HTTP header of the static response (that can be handled with sendfile()). > On the other hand, if you want to add a flag for this, I say > "knock yourself out" -- go ahead and add the flag; it's not > really going to benefit you that much, but it's not going to > really hurt any of the rest of us either, so there's really > no reason to make you not do it. 8-). > > BTW: if you go ahead with this, you should verify that it > also works for the trailers, etc., and you should probably > skip it if you headers > transmit queue depth, or file size > > transmit queue depth, or trailers > transmit queue depth. Currently sendfile() can send the file in not full packets even file is bigger then the transmit queue depth. It can send it in 2 x 1460 + 1176 or 5 x 1460 + 892 packets. Igor Sysoev http://sysoev.ru/en/