Date: Sun, 02 Mar 2003 14:29:11 -0600 From: "Alan L. Cox" <alc@imimic.com> To: Peter Wemm <peter@wemm.org> Cc: arch@freebsd.org Subject: Re: Removal of ENABLE_VFS_IOOPT Message-ID: <3E626997.5005AE71@imimic.com> References: <20030302185332.4D54B2A89E@canning.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Wemm wrote:
>
> "Alan L. Cox" wrote:
> > Before I begin work on vm_object locking, I'd like to remove
> > ENABLE_VFS_IOOPT from the kernel sources. ENABLE_VFS_IOOPT was a
> > work-in-progress by John Dyson to perform zero-copy file system I/O.
> > Unfortunately, it still has some unresolved issues, and no one has taken
> > an active interest in fixing them.
>
> Hold on a second.. I thought the zero-copy folks fixed this up and it
> is required for turning on zero-copy mode etc.
>
> I remember they added code to fix the read() coherency problems.
>
No, they didn't. The zero-copy sockets code introduced a new page-based
copy-on-write mechanism and a new parameter to uiomoveco()
("disposable") that guaranteed that the new mechanism wouldn't be used
for ENABLE_VFS_IOOPT. In contrast, ENABLE_VFS_IOOPT tried to use the
preexisting object-based copy-on-write mechanism. Except for a few
lines of code in kern_subr.c's userspaceco(), the two mechanisms are
distinct. Specifically, the page flipping logic is totally distinct:
vm_pgmoveco() for zero-copy sockets and vm_uiomove() for
ENABLE_VFS_IOOPT.
Someday, someone could attempt to reimplement ENABLE_VFS_IOOPT using the
page-based mechanism, in which case, the four snippets of code in
ffs_vnops.c could be useful. Aside from that, the code which lives in
vm_map.* and vm_object.* is dead weight.
Alan
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E626997.5005AE71>