Date: Wed, 03 Oct 2012 11:42:03 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: freebsd-fs@FreeBSD.org Cc: Baptiste Daroussin <bapt@FreeBSD.org>, Florian Smeets <flo@smeets.im>, Pawel Jakub Dawidek <pjd@FreeBSD.org> Subject: Re: panic: _sx_xlock_hard: recursed on non-recursive sx zfsvfs->z_hold_mtx[i] @ ...cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:1407 Message-ID: <506BFA5B.9060103@FreeBSD.org> In-Reply-To: <20120930122403.GB35915@deviant.kiev.zoral.com.ua> References: <505DB4E6.8030407@smeets.im> <20120924224606.GE79077@ithaqua.etoilebsd.net> <20120925090840.GD35915@deviant.kiev.zoral.com.ua> <20120929154101.GK1402@garage.freebsd.pl> <20120930122403.GB35915@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
on 30/09/2012 15:24 Konstantin Belousov said the following: > The postponing of the reclaim when vnode reserve goes low to the vnlru > process does not solve anything, since you only change the recursion into > the deadlock. > > I discussed an approach for this issue with avg. Basic idea is presented in > the untested patch below. You can specify that some count of the free > vnodes must be present for some dynamic scope, started by > getnewvnode_reserve() function. While staying inside the reserved pool, > getnewvnode() calls would not recurse into vnlru(). The scope is finished > with getnewvnode_drop_reserve(). > > The getnewvnode_reserve() shall be called while no locks are held. > > What do you think ? Here is a patch that makes use of the getnewvnode_reserve API in ZFS: http://people.freebsd.org/~avg/zfs-getnewvnode.diff -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?506BFA5B.9060103>