Re: CVS commit: src/sys/kern

["J. Hannken-Illjes" <hannken%eis.cs.tu-bs.de@localhost>]

On Oct 2, 2011, at 3:26 PM, Adam Hamsik wrote:

> 
> On Oct,Sunday 2 2011, at 3:00 PM, Juergen Hannken-Illjes wrote:
> 
>> Module Name: src
>> Committed By:        hannken
>> Date:                Sun Oct  2 13:00:07 UTC 2011
>> 
>> Modified Files:
>>      src/sys/kern: vfs_vnode.c
>> 
>> Log Message:
>> The path getnewvnode()->getcleanvnode()->vclean()->VOP_LOCK() will panic
>> if the vnode we want to clean is a layered vnode and the caller already
>> locked its lower vnode.
>> 
>> Change getnewvnode() to always allocate a fresh vnode and add a helper
>> thread (vdrain) to keep the number of allocated vnodes within desiredvnodes.
>> 
>> Rename getcleanvnode() to cleanvnode() and let it take a vnode from the
>> lists, clean and free it.
> 
> Thanks for doing this. This should help zfs too I saw couple of 
> panics with zfs which were caused by this.
> 
> Have you done any benchmarks ? when I proposed solution like this 
> main objection was then before vnodes were not allocated from storage
> pool every time(sometime we reused already allocated one). And this may
> affect performance.

I didn't run any benchmark.

As getnewvnode() gets called when a file system sets up a new (not yet cached)
vnode I suppose there are other operations taking much more time like reading
an inode from disk, setting up the inode, creating the genfs_node etc.

We also save the time spent in cleaning the vnode which is now done async to
the allocation.

>> 
>> Reviewed by: David Holland <dholland%netbsd.org@localhost>
>> 
>> Should fix:
>> PR #19110 (nullfs mounts over NFS cause lock manager problems)
>> PR #34102 (ffs panic in NetBSD 3.0_STABLE)
>> PR #45115 (lock error panic when build.sh*3 and daily script is running)
>> PR #45355 (Reader/writer lock error:  rw_vector_enter: locking against 
>> myself)

<snip>

> 
> Regards
> 
> Adam.
> 

--
Juergen Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig 
(Germany)