From owner-freebsd-current Wed Oct 23 21:54:47 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B32F437B401; Wed, 23 Oct 2002 21:54:45 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4AE5943E4A; Wed, 23 Oct 2002 21:54:44 -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 OAA05591; Thu, 24 Oct 2002 14:54:25 +1000 Date: Thu, 24 Oct 2002 15:05:30 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Julian Elischer Cc: Jeff Roberson , Seigo Tanimura , , Subject: Re: Dynamic growth of the buffer and buffer page reclaim In-Reply-To: Message-ID: <20021024143639.P25932-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 23 Oct 2002, Julian Elischer wrote: > Bill Jolitz had a plan for 386BSD where all the buffers were nearly > always unmapped from KVM. He was going to have a number of slots > available for mapping them which would be used in a lifo order > > The number of slots was going to be somehow tunable > but I don't remember the details. We essentially have this now. Most disk blocks are cached in physical pages (VMIO pages) and are disassociated from the the buffer cache and not mapped into vm. Some blocks are mapped into buffers. There are a limited number of slots (nbuf). nbuf hasn't grown nearly as fast as disks or main memory, so what was once a large non-unified buffer cache (nbuf * MAXBSIZE worth of caching) is now just a small number of vm mappings (nbuf of them). > When you wanted to access a buffer, it was mapped for you > (unless already mapped).. It would be unmapped when it's slot > was needed for something else. WHen you accessed a buffer already mapped > it would move it back to the top of the list. > Various events could pre-unmap a buffer. e.g. the related vm object was > closed. (0 references). Almost exactly what we have. It turns out to be not very good, at least in its current implementation, since remapping is too expensive. Things work OK to the extent that remapping is not required, but so would a much simpler implementation that uses less vm and more copying of data (copying seems to be faster than remapping). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message