From owner-freebsd-arch Fri Jul 7 8:43:27 2000 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 9AD1537BFB8 for ; Fri, 7 Jul 2000 08:43:24 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id IAA00597; Fri, 7 Jul 2000 08:43:22 -0700 (PDT) (envelope-from dillon) Date: Fri, 7 Jul 2000 08:43:22 -0700 (PDT) From: Matthew Dillon Message-Id: <200007071543.IAA00597@apollo.backplane.com> To: Bill Fumerola Cc: Alfred Perlstein , Marius Bendiksen , freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops References: <200007070143.SAA96248@apollo.backplane.com> <20000706184859.C25571@fw.wintelcom.net> <20000706215543.Z4034@jade.chc-chimes.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :On Thu, Jul 06, 2000 at 06:48:59PM -0700, Alfred Perlstein wrote: : :> > What may be happening here is stalling in namei(). find and cvsup :> > are very heavy on path lookups and that combined with seek latency :> > on the drive could result in filesystem locks on directories being :> > held for much longer periods of time then normal. Any other process :> > trying to 'open' a file (verses reading or writing an already-open file) :> > would start to stall. :> :> just a note: :> sysctl -w vfs.vmiodirenable=1 :> helps a _lot_. : :I'll turn it on and see if that helps. : :-- :Bill Fumerola - Network Architect / Computer Horizons Corp - CHIMES :e-mail: billf@chimesnet.com / billf@FreeBSD.org Ahhhhh. We're waiting with baited breath! If setting vmiodirenable helps then what's probably happening is that the buffer cache's malloc space is being blown away by all the path lookups (due to the reading of all the directories). Turning on vmiodirenable would greatly increase the amount of memory available for caching directories. For the other person who asked what vmiodirenable is: It's a mechanism to allow the system's VM page cache (the master page cache in the system) to cache file pages associated with directories. With this turned on the system is able to cache at least 10x as many directories. With the option turned off (the default, see note below), the buffer cache implements a special 'malloc space' to hold directory pages. This space is very small, and we can't make it any bigger without really screwing up the system. sysctl -a | fgrep malloc My intention was to turn on vmiodirenable by default, but I got stalled on an obscure bug or two related to softupdates. That was a long time ago.. at least 6 months, probably more. It could very well be that the problems no longer exist. My intention is also at some point to remove the crufty malloc space feature in the buffer cache. It was originally designed to 'save memory' by packing small filesystem blocks rather then using the mandatory minimum of one page (4K on i386) that anything backed by the VM Page cache requires. For example, most small directories fit in much less then 4K. The concept is sound, but the implementation has severe scaling problems. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message