From owner-freebsd-current Mon Aug 19 11:15:55 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6535637B400; Mon, 19 Aug 2002 11:15:51 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DB8243E70; Mon, 19 Aug 2002 11:15:49 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id SAA27600; Mon, 19 Aug 2002 18:15:42 GMT Date: Tue, 20 Aug 2002 04:21:11 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Matthew Dillon Cc: "Semen A. Ustimenko" , , Maxim Konovalov , Robert Watson , Subject: Re: sendfile() change (Was: Re: cvs commit: src/sys/kern uipc_syscalls.c) In-Reply-To: <200208191649.g7JGnXIR077528@apollo.backplane.com> Message-ID: <20020820040605.N20882-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 19 Aug 2002, Matthew Dillon wrote: > :Why can't we get rid of VOP_READ(.. UIO_NOCOPY...) call in sendfile()? > :Me, I can't quite understand what UIO_NOCOPY means... As long as > :sendfile() function already plays around pages, it can use VOP_GETPAGES(). > :The following patch looks works for me. Could anybody said if it has any > :benefits or not? > UIO_NOCOPY tells the filesystem to not bother copying the data > into the passed buffer but to instead simply load it into the buffer > cache / VM backing store. > > While this adds buffer cache management overhead, it ought to yield > far greater performance over doing a VOP_GETPAGES() at this point > because the filesystem will be able to do clustered reads and > read-ahead (potentially a 64K I/O) instead of a 4K I/O. > > An alternative would be to cluster the VM pages in sendfile() and > call VOP_GETPAGES() on a block of pages instead of just one. I'm > guessing that is not being done because it's about 100 lines of code > to do it right. It's easier just to call vn_rdwr() and let the > system do the clustering. This argument seems to apply to exec_map_first_pages() too. It does its own blocking to get up to VM_INITIAL_PAGEIN (normally 16) pages using only about 50 lines of code, but does this slightly wrong. It doesn't honor the device limit of si_iosize_max, unlike filesystem code. This used to break exec on zip drives (si_iosize_max used to be 32K, but VM_INITIAL_PAGEIN pages is 64K bytes on i386's). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message