From owner-freebsd-hackers Sun Sep 23 3:40:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id D790C37B41E for ; Sun, 23 Sep 2001 03:40:41 -0700 (PDT) Received: (from dillon@localhost) by earth.backplane.com (8.11.6/8.11.2) id f8NAeXw86352; Sun, 23 Sep 2001 03:40:33 -0700 (PDT) (envelope-from dillon) Date: Sun, 23 Sep 2001 03:40:33 -0700 (PDT) From: Matt Dillon Message-Id: <200109231040.f8NAeXw86352@earth.backplane.com> To: Poul-Henning Kamp Cc: David Greenman , Seigo Tanimura , bright@wintelcom.net, hackers@FreeBSD.ORG Subject: Re: Conclusions on... was Re: More on the cache_purgeleafdirs() routine References: <96469.1001237641@critter> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :> VM Page Cache, and thus not be candidates for reuse anyway. So my patch :> has a very similar effect but without the overhead. : :Back when I rewrote the VFS namecache back in 1997 I added that :clause because I saw directories getting nuked in no time because :there were no pages holding on to them (device nodes were even worse!) : :So refresh my memory here, does directories get pages cached in VM if :you have vfs.vmiodirenable=0 ? : :What about !UFS filesystems ? Do they show a performance difference ? : :Also, don't forget that if the VM system gave preferential caching to :directory pages, we wouldn't need the VFS-cache very much in the first :place... : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 Ah yes, vmiodirenable. We should just turn it on by default now. I've been waffling too long on that. With it off the buffer cache will remember at most vfs.maxmallocspace worth of directory data (read: not very much), and without VMIO backing, which means vnodes could be reclaimed immediately. Ah! Now I see why that clause was put in... but it's obsolete now if vmiodirenable is turned on, and it doesn't scale well to large-memory machines if it is left in. If we turn vmiodirenable on then directory blocks get cached by the VM system. There is no preferential treatment of directory blocks but there doesn't need to be, the VM system does a very good job figuring out which blocks to keep and which not to. vfs.vmiodirenable=0 works well for small lightly loaded systems but doesn't scale at all. vfs.vmiodirenable=1 works well for any sized system, even though there's considerable storage ineffeciencies with small directories, because the VM Page algorithms compensate (and scale). Small systems with fewer directories don't see the vnode scaling problem because there are simply not enough directories to saturate the vnode/inode malloc areas. Large systems with a greater number of directories blow up the vnode/inode malloc space. I'll run some buildworld tests tomorrow. Er, later today. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message