From owner-svn-src-head@FreeBSD.ORG Mon Oct 15 13:20:48 2012 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DD8F19F6; Mon, 15 Oct 2012 13:20:48 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6FC0E8FC14; Mon, 15 Oct 2012 13:20:46 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA10699; Mon, 15 Oct 2012 16:20:44 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <507C0DAC.1040606@FreeBSD.org> Date: Mon, 15 Oct 2012 16:20:44 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121012 Thunderbird/16.0.1 MIME-Version: 1.0 To: John Baldwin Subject: Re: svn commit: r241556 - in head/sys: kern sys References: <201210141943.q9EJhclS029533@svn.freebsd.org> <201210150837.04943.jhb@freebsd.org> In-Reply-To: <201210150837.04943.jhb@freebsd.org> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Konstantin Belousov X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 13:20:49 -0000 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