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 <dholl...@netbsd.org> >> >> 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 - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
