From owner-freebsd-current  Mon Apr 16  0:50:41 2001
Delivered-To: freebsd-current@freebsd.org
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by hub.freebsd.org (Postfix) with ESMTP id 8744C37B42C
	for <current@FreeBSD.ORG>; Mon, 16 Apr 2001 00:50:37 -0700 (PDT)
	(envelope-from bde@zeta.org.au)
Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102])
	by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id RAA13814;
	Mon, 16 Apr 2001 17:50:19 +1000
Date: Mon, 16 Apr 2001 17:49:25 +1000 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-Sender: bde@besplex.bde.org
To: "Justin T. Gibbs" <gibbs@scsiguy.com>
Cc: Matt Dillon <dillon@earth.backplane.com>,
	Doug Barton <DougB@DougBarton.net>,
	"'current@freebsd.org'" <current@FreeBSD.ORG>
Subject: Re: FW: Filesystem gets a huge performance boost 
In-Reply-To: <200104160259.f3G2xqs06321@aslan.scsiguy.com>
Message-ID: <Pine.BSF.4.21.0104161724210.6152-100000@besplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Sun, 15 Apr 2001, Justin T. Gibbs wrote:

> >    There's no downside, really.
> 
> It just seems inelegant to have a system that, on paper, is
> so inefficient.  Can't we do better?

Sure.  Don't discard buffer contents when recycling a B_MALLOC'ed buffer,
but manage it using a secondary buffer cache that doesn't have as much
overhead as the primary one (in particular, don't reserve BKVASIZE bytes
of kernel virtual address space for each secondary buffer).  This would
be even more inelegant, and more complicated, but not so inefficient.

Bruce


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message