From owner-cvs-src@FreeBSD.ORG Thu Mar 27 09:47:58 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBC9037B405 for ; Thu, 27 Mar 2003 09:47:58 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 8655C43FBD for ; Thu, 27 Mar 2003 09:47:57 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 29776 invoked by uid 1000); 27 Mar 2003 17:47:58 -0000 Date: Thu, 27 Mar 2003 09:47:58 -0800 (PST) From: Nate Lawson To: Tor.Egge@cvsup.no.freebsd.org In-Reply-To: <20030327135934T.tegge@cvsup.no.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-23.2 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/conf NOTES files options src/sys/kern vfs_bio.c src/sys/ufs/ffs ffs_rawread.c ffs_vnops.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2003 17:48:00 -0000 On Thu, 27 Mar 2003 Tor.Egge@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