Date: Sat, 22 Sep 2001 15:09:52 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: David Greenman <dg@root.com> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, bright@wintelcom.net, hackers@FreeBSD.ORG Subject: Re: More on the cache_purgeleafdirs() routine Message-ID: <200109222209.f8MM9qs82489@earth.backplane.com> References: <88901.1001191415@critter> <200109222121.f8MLLHe82202@earth.backplane.com> <20010922141934.C28469@nexus.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:> Well, wait a sec... all I do is zap the namei cache for the vnode. The
:> check to see if the vnode's object still has resident pages is still in
:> there so I don't quite understand how I turned things around. In my
:> tests it appears to cache vnodes as long as there are resident pages
:> associated with them.
:
: Sounds like a very good first step. I would like to point out that the
:problem may still occur on large memory systems with a few hundred thousand
:tiny files (that consume just one page of memory). There really needs to
:be a hard limit as well - something low enough so that the FFS node KVM malloc
:limit isn't reached, but still large enough to not significantly pessimize
:the use of otherwise free physical memory for file caching. Considering that
:a 4GB machine has about 1 million pages and that the malloc limit hits at
:about 250,000 vnodes, this is an impossible goal to acheive in that case
:without increasing the malloc limit by at least 4X. Of course this many
:1 page files is extremely rare, however, and I don't think we should optimize
:for it.
:
:-DG
Yes, it's easy to hit 250,000 vnodes. On a 512M machine I can hit 80,000
vnodes without breaking a sweat. The reason is simply due to the way
the VM Page cache works... even medium sized files can wind up with
just one page in core after a while. It does stabilize, but at a level
that is too high for comfort.
On -stable we've exasperated the problem because inode->i_dirhash
increased the size of struct inode to 260 bytes, causing it to use a 512
byte MALLOC chunk (FFS node malloc type) instead of a 256 byte chunk.
I'm working with Ian to get struct inode back down to 256 bytes (It isn't
a problem in -current). Unfortunately this introduced additional issues
in our 4.4 release for people with > 2GB of ram and at least one person
is seeing system deadlocks from it.
I think it would be fairly easy to release VM pages underlying objects
associated with vnodes being reused when we determine that we have too
many vnodes. We would have to be careful, because what Poul said really
would come true if we blindly released VM pages based on the vnode free
list! Alternatively we might be able to adjust the VM paging system to
release nearby VM pages in idle VM objects, getting them cleared out more
quickly and allowing their vnodes to be reused without compromising
the VM system's excellent page selection code. At least then it would
truely take a million 'small' files to create an issue.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200109222209.f8MM9qs82489>