Date: Sun, 02 Mar 2003 12:52:50 -0800 From: Peter Wemm <peter@wemm.org> To: "Alan L. Cox" <alc@imimic.com> Cc: arch@freebsd.org Subject: Re: Removal of ENABLE_VFS_IOOPT Message-ID: <20030302205250.E53D22A89E@canning.wemm.org> In-Reply-To: <3E626997.5005AE71@imimic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Alan L. Cox" wrote:
> 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.
Perhaps my confusion comes from earlier versions of the zero copy work
when it was necessary to turn on ENABLE_VFS_IOOPT.
Personally, I dont think the complexity is worth it. I don't mind removing
it, as long as it is for the right reasons. I thought it had been fixed,
but since it hasn't I'll shut up. I think we'd get more mileage from
optimizing the data copying routines. There are a whole host of new
instructions that came with SSE that we are not taking advantage of yet. We
can probably get a factor of 5 improvement in general purpose data copying
speeds with this stuff on modern cpus.
Cheers,
-Peter
--
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
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?20030302205250.E53D22A89E>