Date: Mon, 15 Oct 2012 16:20:44 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Konstantin Belousov <kib@FreeBSD.org> Subject: Re: svn commit: r241556 - in head/sys: kern sys Message-ID: <507C0DAC.1040606@FreeBSD.org> In-Reply-To: <201210150837.04943.jhb@freebsd.org> References: <201210141943.q9EJhclS029533@svn.freebsd.org> <201210150837.04943.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
on 15/10/2012 15:37 John Baldwin said the following: > On Sunday, October 14, 2012 3:43:37 pm Konstantin Belousov wrote: >> Author: kib >> Date: Sun Oct 14 19:43:37 2012 >> New Revision: 241556 >> URL: http://svn.freebsd.org/changeset/base/241556 >> >> Log: >> Add a KPI to allow to reserve some amount of space in the numvnodes >> counter, without actually allocating the vnodes. The supposed use of >> the getnewvnode_reserve(9) is to reclaim enough free vnodes while the >> code still does not hold any resources that might be needed during the >> reclamation, and to consume the slack later for getnewvnode() calls >> made from the innards. After the critical block is finished, the >> caller shall free any reserve left, by getnewvnode_drop_reserve(9). > > Can you describe an intended use-case for this? > The use-case is primarily ZFS, but could be useful in other filesystems. The idea is to avoid recursion back into the filesystem code when it is written in such a way that (1) it must hold internal locks around getnewvnode call and (2) it doesn't handle well calls to vop_inactive/vop_reclaim when the said internal locks are already held. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?507C0DAC.1040606>