From owner-freebsd-current Mon Mar 6 17:41:10 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA28627 for current-outgoing; Mon, 6 Mar 1995 17:41:10 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id RAA28606 for ; Mon, 6 Mar 1995 17:41:02 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id LAA02797; Tue, 7 Mar 1995 11:36:16 +1000 Date: Tue, 7 Mar 1995 11:36:16 +1000 From: Bruce Evans Message-Id: <199503070136.LAA02797@godzilla.zeta.org.au> To: davidg@Root.COM, terry@cs.weber.edu Subject: Re: more ETXTBSY bugs Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk > It's never a good idea to not use free memory for file caching. Using >memory for file caching that is currently being used to cache VM pages may >not be such a good idea. We've tried several different approaches - the >current scheme is escentially to not disturb pages that have faulted in >and only use memory that would otherwise be free. This sets the upper limit. >The lower limit comes from the fact that pages are always allocated when >needed for buffers (even if these pages have to come from a process's VM); >thus the total number of buffers sets a lower limit on how small the cache >can shrink. This number is currently about 5% of memory, and we our currently >considering increasing this to 10%. Actually, the lower limit is about 0.5% of memory. On my 16MB system, there are only 178 buffers, so if all buffers have size 512, then they only hold 89K. All buffers may have size 512 if the most-used file system has a block size of 512 or a fragment size of 512 and there are a lot of fragments. Bruce