In message <[EMAIL PROTECTED]>, Matt Dillon writes:
> Again, keep in mind that the namei cache is strictly throw-away, but
> entries can often be reconstituted later by the filesystem without I/O
> due to the VM Page cache (and/or buffer cache depending on
> vfs.vmiodirenable). So as with the buffer cache and inode cache,
> the number of entries can be limited without killing performance or
> 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.
We can safely say that you cannot profitably _increase_ the size of
the namecache, except for the negative entries where raw statistics
will have to be the judge of the profitability of the idea.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
