Skip site navigation (1)Skip section navigation (2)
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>