Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 23 Sep 2001 11:34:01 +0200
From:      Poul-Henning Kamp <phk@critter.freebsd.dk>
To:        Matt Dillon <dillon@earth.backplane.com>
Cc:        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:  <96469.1001237641@critter>
In-Reply-To: Your message of "Sat, 22 Sep 2001 23:42:25 PDT." <200109230642.f8N6gPj84955@earth.backplane.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <200109230642.f8N6gPj84955@earth.backplane.com>, Matt Dillon writes:


>    My patch doesn't make a distinction but assumes that (A) will tend to
>    hold for higher level directories: that is, that higher level directories
>    tend to be accessed more often and thus will tend to have pages in the 
>    VM Page Cache, and thus not be candidates for reuse anyway.  So my patch
>    has a very similar effect but without the overhead.

Back when I rewrote the VFS namecache back in 1997 I added that
clause because I saw directories getting nuked in no time because
there were no pages holding on to them (device nodes were even worse!)

So refresh my memory here, does directories get pages cached in VM if
you have vfs.vmiodirenable=0 ?  

What about !UFS filesystems ?  Do they show a performance difference ?

Also, don't forget that if the VM system gave preferential caching to
directory pages, we wouldn't need the VFS-cache very much in the first
place...

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | 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 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?96469.1001237641>