Date: Sun, 23 Sep 2001 14:09:46 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Wilko Bulte <wkb@freebie.xs4all.nl> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, David Greenman <dg@root.com>, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, bright@wintelcom.net, hackers@FreeBSD.ORG Subject: Re: Conclusions on... was Re: More on the cache_purgeleafdirs() routine Message-ID: <200109232109.f8NL9kU88657@earth.backplane.com> References: <96469.1001237641@critter> <200109231040.f8NAeXw86352@earth.backplane.com> <20010923124702.B9914@freebie.xs4all.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
:Has the problem of small-memory machines (< 64M IIRC) solved now? As I
:understand it vmiodirenable is counter-productive for these boxes.
:Maybe one could decide on-boot whether the amount of mem is enough to
:make it useful?
:
:Just a thought of course.
:
:| / o / /_ _ email: wilko@FreeBSD.org
Small memory machines never had a problem. Even though there can be
considerable memory inefficiencies using vmiodirenable (e.g. a directory
less then 512 bytes eats 512 bytes of physical ram with vmiodirenable
turned off, and 4K with it turned on), there are two compensating factors:
First, the VM Paging cache is a cache, so the cached directory blocks can
be thrown away. Second, the VM Page cache has all of memory to play
with while the buffer cache with vmiodirenable turned off on a 64MB
machine will reserve less then a megabyte to cache directories. #2 is
important because it leads to more I/O which has a far greater effect
on the system then memory waste. Also, if you look at the typical
program's memory footprint and assume that actively accessed directories
eat 4K, the memory used to hold the active directories winds up being
almost nothing compared to the RSS of the program using those directories.
Single-use directories (e.g. make buildworld) are recycled in the VM Page
cache and do not eat as much memory as you might otherwise think.
So even though the memory inefficiency can be up to 8:1 (4096/512),
this factor is somewhat deceptive in regards to the actual effect on
the system.
-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?200109232109.f8NL9kU88657>
