From owner-freebsd-hackers Mon Apr 19 13:41:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (Postfix) with SMTP id A09D3150B3 for ; Mon, 19 Apr 1999 13:41:40 -0700 (PDT) (envelope-from dyson@dyson.iquest.net) Received: (qmail 7578 invoked from network); 19 Apr 1999 20:39:03 -0000 Received: from dyson.iquest.net (198.70.144.127) by iquest3.iquest.net with SMTP; 19 Apr 1999 20:39:03 -0000 Received: (from root@localhost) by dyson.iquest.net (8.9.1/8.9.1) id PAA20464; Mon, 19 Apr 1999 15:39:00 -0500 (EST) From: "John S. Dyson" Message-Id: <199904192039.PAA20464@dyson.iquest.net> Subject: Re: Directories not VMIO cached at all! In-Reply-To: <199904182002.NAA81858@apollo.backplane.com> from Matthew Dillon at "Apr 18, 99 01:02:47 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Mon, 19 Apr 1999 15:38:59 -0500 (EST) Cc: dg@root.com, hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I see an advantage both ways. Not only are we able to use the VM cache > to cache directories ( and thus scale directory operations to memory ), > but I don't think there is even a downside to mapping whole pages even for > small directories. The reason is simple: When you access small > directories you tend to access specific files in said directories. When > you access specific files, there's a good chance they will be in the namei > cache. If they are in the namei cache, the VMIO mapping will not be > referenced very often for most small directories which means that the > VM cache will throw it away. Hence, no waste. > I cannot believe that you said that: The size of the cache buffers are then up to 8X larger when using a whole page instead of a 512byte buffer. BTW, VMIO is a misnomer, and I named it... VMIO was an earlier incarnation, and some of it spilled into the existant code. Again, do a study to find out if the internal fragmentation makes things worse. Don't depend on the VM code to just "throw" things away -- if you can make considered decisions instead of deferring them to a policy somewhere, make the decision... John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message