Date: Sun, 5 Oct 2003 01:40:52 -0400 (EDT) From: Jeff Roberson <jroberson@chesapeake.net> To: Jeff Roberson <jeff@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern vfs_subr.c Message-ID: <20031005013726.I99666-100000@mail.chesapeake.net> In-Reply-To: <200310050535.h955ZgCT072353@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I tested this by doing a buildworld on a machine with maxvnodes set to 1000. Needless to say, there was plenty of recycling. This change in particular provides a clear path for filesystems to follow when manipulating vnodes that are found on non usecounted lists. As per usual, I haven't moved giant at all, I'm just spinning my wheels. ;-) Cheers, Jeff On Sat, 4 Oct 2003, Jeff Roberson wrote: > jeff 2003/10/04 22:35:42 PDT > > FreeBSD src repository > > Modified files: > sys/kern vfs_subr.c > Log: > - Rename vcanrecycle() to vtryrecycle() to reflect its new role. > - In vtryrecycle() try to vgonel the vnode if all of the previous checks > passed. We won't vgonel if someone has either acquired a hold or usecount > or started the vgone process elsewhere. This is because we may have been > removed from the free list while we were inspecting the vnode for > recycling. > - The VI_TRYLOCK stops two threads from entering getnewvnode() and recycling > the same vnode. To further reduce the likelyhood of this event, requeue > the vnode on the tail of the list prior to calling vtryrecycle(). We can > not actually remove the vnode from the list until we know that it's > going to be recycled because other interlock holders may see the VI_FREE > flag and try to remove it from the free list. > - Kill a bogus XXX comment. If XLOCK is set we shouldn't wait for it > regardless of MNT_WAIT because the vnode does not actually belong to > this filesystem. > > Revision Changes Path > 1.464 +32 -26 src/sys/kern/vfs_subr.c >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031005013726.I99666-100000>