cvs commit: src/sys/conf NOTES files options src/sys/kern vfs_bio.c src/sys/ufs/ffs ffs_rawread.c ffs_vnops.c

[Nate Lawson]

On Thu, 27 Mar 2003 Tor.Egge at cvsup.no.freebsd.org wrote:
> > I am neither impressed nor thrilled by this.
> > 
> > We already have pretty firm plans for converting struct bio from a
> > "mapped KVM" to a a "virtual/physical scatter/gather" thing in the
> > 6-current, and that is the correct way to solve this problem.
> 
> That doesn't help getting the data to the userland buffer instead of
> into the buffer cache.

Exactly.  Also, in response to Eivind, O_DIRECT does make sense in that if
I set the flag, I want all accesses to avoid the buffer cache.  This code
just takes the semantics one step farther in that data does not even hit
the buffer cache at all (before being copied out to userland) but is
DMA'd directly to userland.
 
> > If this is a crucial feature for 5-stable, I would far rather add
> > we push ahead with that plan, than see more pbuf based hacks in the
> > kernel.
> 
> Applications that perform their own caching can have a very low hit
> rate in the buffer cache, and at some point the memory bandwith usage
> copying data from the buffer cache to userland becomes much more
> significant than the occational buffer cache hit.

This is very useful for scsi_target in that data is already sent directly
from userland (via cam_periph_mapmem) and now the backing store can be
directly read/written from userland.  This means only one copy of data is
buffered in memory and there is a complete zero-copy path end-to-end.  
sendfile(2) is nice but only works for sockets.  Instead of zero-copy
interfaces that take two different fds and pass data between them, it's
more versatile to have each major mid-layer (sockets, files, CAM, etc.)
have a zero-copy path and then allow user applications to do the muxing.

-Nate