Date: Thu, 12 Apr 2001 14:24:36 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Rik van Riel <riel@conectiva.com.br>, David Xu <bsddiy@21cn.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: vm balance Message-ID: <200104122124.f3CLOaq25845@earth.backplane.com> References: <59487.987108936@critter>
next in thread | previous in thread | raw e-mail | index | archive | help
:>:> scaleability.
:>:
:>:Uhm, that is actually not true.
:>:
:>:We keep namecache entries around as long as we can use them, and that
:>:generally means that recreating them is a rather expensive operation,
:>:involving creation of vnode and very likely a vm object again.
:>
:> The vnode cache is a different cache. positive namei hits will
:> reference a vnode, but namei elements can be flushed at any
:> time without flushing the underlying vnode.
:
:Right, but doing so means that to refind that vnode from the name
:is (comparatively) very expensive.
:
:--
:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
:phk@FreeBSD.ORG | TCP/IP since RFC 956
The only thing that is truely expensive is having to physically
scan a large directory in order to instantiate a new namei
record. Everything else is inexpensive by comparison (by two
orders of magnitude!), even constructing new vnodes.
Without vmiodirenable turned on, any directory exceeding
vfs.maxmallocbufspace becomes extremely expensive to work with
O(N * diskIO). With vmiodirenable turned on huge directories
are O(N), but have a better chance of being in the VM page cache
so cost proportionally less even though they don't do any
better on a relative scale.
-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?200104122124.f3CLOaq25845>