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>