Date: Sat, 22 Sep 2001 23:57:04 -0700 From: David Greenman <dg@root.com> To: Matt Dillon <dillon@earth.backplane.com> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, 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: <20010922235704.D28469@nexus.root.com> In-Reply-To: <200109230642.f8N6gPj84955@earth.backplane.com>; from dillon@earth.backplane.com on Sat, Sep 22, 2001 at 11:42:25PM -0700 References: <88901.1001191415@critter> <200109222121.f8MLLHe82202@earth.backplane.com> <20010922141934.C28469@nexus.root.com> <200109230642.f8N6gPj84955@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Well, this has turned into a rather sticky little problem. I've > spent all day going through the vnode/name-cache reclaim code, looking > both at Seigo's cache_purgeleafdirs() and my own patch. Can you forward me your patch? I'd like to try it out on some machines in the TSI lab. > The bigger problem is exactly as DG has stated... it isn't the namei > cache that is our enemy, it's the VM Page cache preventing vnodes > from being recycled. > > For the moment I believe that cache_purgeleafdirs() or my patch solves > the problem well enough that we can run with it for a while. The real > solution, I believe, is to give us the ability to take cached VM Pages > associated with a file and rename them to cached VM Pages associated > with the filesystem device - we can do this only for page-aligned > blocks of course, not fragments (which we would simply throw away)... > but it would allow us to reclaim vnodes independant of the VM Page cache > without losing the cached pages. I think this is doable but it will > require a considerable amount of work. It isn't something I can do in a > day. I also believe that this can dovetail quite nicely into the I/O > model that we have slowly been moving towards over the last year > (Poul's work). Inevitably we will have to manage device-based I/O > on a page-by-page basis and being able to do it via a VM Object seems > to fit the bill in my opinion. Hmmm. This would seem to be a step back to the days when caching was done relative to the device as opposed to the file-relative scheme we have now. One of the problems with the old scheme as I recall is that some filesystems like NFS don't have a 'device' and thus no physical block numbers to associate the cached pages with. There is also some cost in moving the pages between the file object and the device object. For these reasons, I would prefer that we keep the existing model, but just make sure that we can handle the degenerate case of one page per file object. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. 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?20010922235704.D28469>