This is a discussion on Re: Freeing vnodes. - FreeBSD ; On Mon, 14 Mar 2005, Stephan Uphoff wrote: > On Mon, 2005-03-14 at 21:38, Jeff Roberson wrote: > > I have a patch at http://www.chesapeake.net/~jroberson/freevnodes.diff > > that allows us to start reclaiming vnodes from the free list and release ...
On Mon, 14 Mar 2005, Stephan Uphoff wrote:
> On Mon, 2005-03-14 at 21:38, Jeff Roberson wrote:
> > I have a patch at http://www.chesapeake.net/~jroberson/freevnodes.diff
> > that allows us to start reclaiming vnodes from the free list and release
> > their memory. It also changes the semantics of wantfreevnodes, and makes
> > getnewvnode() much prettier.
> > The changes attempt to keep some number of vnodes, currently 2.5% of
> > desiredvnodes, that are free in memory. Free vnodes are vnodes which
> > have no references or pages in memory. For example, if an application
> > simply stat's a vnode, it will end up on the free list at the end of the
> > operation. The algorithm that is currently in place will immediately
> > recycle these vnodes once there is enough pressure, which will cause us to
> > do a full lookup and reread the inode, etc. as soon as it is stat'd again.
> > This also removes the recycling from the getnewvnode() path. Instead, it
> > is done by a new helper function that is called from vnlru_proc(). This
> > function just frees vnodes from the head of the list until we reach our
> > wantfreevnodes target.
> > I haven't perf tested this yet, but I have a box that is doing a
> > buildworld with a fairly constant freevnodes count which shows that vnodes
> > are actually being uma_zfree'd.
> > Comments? Anyone willing to do some perf tests for me?
> > Thanks,
> > Jeff
> Just looked at the raw diff and might have missed it - how are the
> parent directory "name" cache entries ( vnode fields v_dd, v_ddid)
Just as they were before, by calling cache_purge.
email@example.com mailing list
To unsubscribe, send any mail to "firstname.lastname@example.org"