Date: Mon, 19 Apr 1999 13:38:09 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Arjan de Vet <Arjan.deVet@adv.iae.nl> Cc: hackers@FreeBSD.ORG Subject: Re: Directories not VMIO cached at all! Message-ID: <199904192038.NAA90197@apollo.backplane.com> References: <199904171844.LAA75452@apollo.backplane.com> <199904192019.WAA05340@adv.iae.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
:What is needed I think is a (preferably) sysctl variable which would
:favor metadata w.r.t. caching whenever possible. Matt's patch makes
:directories VMIO data too, so I don't know whether we still can decide
:easily whether a cached block is metadata or not (I just started
:studying the buffer cache code this weekend and it's quite complicated).
:
:Arjan
Hint: Ignore the buffer cache code until you understand the VM cache
code, vm/vm_page.c.
To answer your question re: metadata vs filedata. Neither the buffer
cache nor the VM system can really tell unless they run through and check
the vnode structure type. I don't think that weighting it would help
anyway. The VM system does a better job then the buffer cache figuring
out which pages it can throw away and which it needs to keep because it
has a larger statistical sample to work with. You should be able to
let it operate without any major tweaking.
One thing that could be effecting the caching is the size of the vnode
cache. The 'kern.maxvnodes' sysctl variable may help here ( though I
suggest upping 'maxusers' rather then upping kern.maxvnodes to ensure
that you do not run out of KVM, or perhaps doing both ).
The VM system caches pages. Pages belong to objects. Objects belong
either to running processes in an unassociated manner ( i.e. program RSS
or copy-on-write pages ), or to vnodes. 'systat -vm 1' will give you
a good synopsis of the vnode cache.
Both files and directories are represented by vnodes. This means that
if the kernel has to throw a vnode away, it has to throw the VM cache pages
associated with the vnode's object away too.
I think this will provide a natural weighting towards the directory vnodes
from the perspective of a system running squid, because the directories
are accessed far more often then any given file. This should cause the
file vnodes to be thrown away first and thus weight the VM cache a bit
more towards the directories.
--
Another issue the namei cache. Squid is probably defeating the namei
cache due to the huge number of file misses that occur. Even with
the negative caching, directories are going to be scanned. The VMIO
patch ought to make a huge difference for your application.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?199904192038.NAA90197>