From owner-freebsd-hackers Mon Apr 19 14: 6:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 850A8156AA for ; Mon, 19 Apr 1999 14:06:51 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id OAA90382; Mon, 19 Apr 1999 14:04:19 -0700 (PDT) (envelope-from dillon) Date: Mon, 19 Apr 1999 14:04:19 -0700 (PDT) From: Matthew Dillon Message-Id: <199904192104.OAA90382@apollo.backplane.com> To: "John S. Dyson" Cc: dmlb@ragnet.demon.co.uk (Duncan Barclay), hackers@FreeBSD.ORG Subject: Re: Directories not VMIO cached at all! References: <199904192042.PAA20471@dyson.iquest.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> Directory Size Count :> 512 34354 :> 1024 963 :> 1536 358 :> 2048 245 :.... :> :Your results show the wastefulness of using a page for everything. There :is NO gain from wasting the memory by rounding everything up to a page. :If buffers are not used for sub-page entities, another scheme should be :used. I fear expediency or sloppiness will prevail. : :John You are still ignoring the several points I brought up. I wish you would address them. I put forth several theories as to why there would be relatively little waste. * Just because there are 34354 512 byte directories does not mean there are 34354 512 byte directories in active use! * The namei cache will tend to fully-cache smaller directories ( or at least produce a very high percentage of cache hits ) allowing their VMIO-backed directories to go away. This is my theory, anyway. * Larger directories benefit greatly from being VM backed, and smaller ones in certain configurations - such as a squid configuration or a general large-memory configuration -- also benefit because the VM cache scales to memory and the buffer cache does not. * Smaller systems with less memory have fewer processes which are hitting fewer directories actively, so the wasteage scales down as well. * I think the issue devolves down into how much I/O we can avoid. I don't really care how much temporary memory we waste. I/O costs a lot more then a bcopy. The existing B_MALLOC buffer cache code does not scale. At all. Even my small test systems - with 48MB of ram - appear to benefit from the change! It is turning out that far more memory is being used by the programs accessing the directory structure then is being eaten by the directory structure. Considering the immensly critical nature of the directory structure, if there were any single place where I'd be willing to waste some bytes it would be there. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message