: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?
:Index: uipc_syscalls.c
: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);
:                       vm_page_io_finish(pg);

    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. 

                                        Matthew Dillon 
                                        <[EMAIL PROTECTED]>

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to