From owner-cvs-all@FreeBSD.ORG Thu Mar 27 05:59:37 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BED3237B401; Thu, 27 Mar 2003 05:59:37 -0800 (PST) Received: from cvsup.no.freebsd.org (c2h5oh.idi.ntnu.no [129.241.103.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9347D43F93; Thu, 27 Mar 2003 05:59:36 -0800 (PST) (envelope-from Tor.Egge@cvsup.no.freebsd.org) Received: from localhost (localhost [127.0.0.1]) by cvsup.no.freebsd.org (8.12.6/8.12.6) with ESMTP id h2RDxY4k062269; Thu, 27 Mar 2003 13:59:35 GMT (envelope-from tegge@cvsup.no.freebsd.org) To: phk@phk.freebsd.dk From: Tor.Egge@cvsup.no.freebsd.org In-Reply-To: <30005.1048751103@critter.freebsd.dk> References: <200303262340.h2QNegJg065498@repoman.freebsd.org> <30005.1048751103@critter.freebsd.dk> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20030327135934T.tegge@cvsup.no.freebsd.org> Date: Thu, 27 Mar 2003 13:59:34 GMT Sender: Tor Egge X-Dispatcher: imput version 20000228(IM140) Lines: 19 X-Spam-Status: No, hits=-17.9 required=5.0 tests=AWL,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES 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-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2003 13:59:41 -0000 > 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. > 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. - Tor Egge