: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?
:RCS file: /home/ncvs/src/sys/kern/uipc_syscalls.c,v
:retrieving revision 1.110
:diff -u -r1.110 uipc_syscalls.c
:--- uipc_syscalls.c 20 May 2002 05:41:03 -0000 1.110
:+++ uipc_syscalls.c 13 Aug 2002 17:54:33 -0000
:@@ -1820,10 +1820,7 @@
: bsize = vp->v_mount->mnt_stat.f_iosize;
: vn_lock(vp, LK_SHARED | LK_NOPAUSE | LK_RETRY, td);
:- error = vn_rdwr(UIO_READ, vp, NULL, MAXBSIZE,
:- trunc_page(off), UIO_NOCOPY, IO_NODELOCKED |
:- IO_VMIO | ((MAXBSIZE / bsize) << 16),
:- td->td_ucred, NULL, td);
:+ error = VOP_GETPAGES(vp, &pg, PAGE_SIZE, 0, 0);
: VOP_UNLOCK(vp, 0, td);
: vm_page_flag_clear(pg, PG_ZERO);
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.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message