Re: serious performance regression in .41

[christos%zoulas.com@localhost (Christos Zoulas)]

On May 22,  6:23pm, campbell+netbsd-tech-kern%mumble.net@localhost (Taylor R 
Campbell) wrote:
-- Subject: Re: serious performance regression in .41

|    Date: Thu, 22 May 2014 16:47:10 +0000 (UTC)
|    From: christos%astron.com@localhost (Christos Zoulas)
| 
|    I am testing this now:
| 
|    http://www.netbsd.org/~christos/vnode_iterator.diff
| 
| vfs_vnode_iterator_next should take the interlock and check for
| VI_CLEAN|VI_CHANGING (and perhaps vwait if VI_CHANGING) before calling
| the selector.  VI_CLEAN vnodes (i.e., vnodes the system has called
| VOP_RECLAIM on to release) shouldn't be exposed outside vfs_vnode.c.
| 
| There's another small problem which is that access to v_data is
| generally not really correct without holding the vnode lock (depends
| on the file system, but for most of them).  So, e.g., the test of
| inode update flags in ffs_sync_selector is sketchy.  However, this is
| probably safe for now, and is what we've been doing all along.
| 
| As a longer-term alternative, perhaps we ought to have a separate
| queue for dirty vnodes (i.e., vnodes with pending stuff to write back
| to disk).  Then sync(2) wouldn't pay for vnodes it needn't actually
| mess with.

I am taking the interlock now, but I am not checking the vnode flags.
It is a simple change to make centrally now. I see the performance back
to where it was before the vnode iterator refactoring. I had a small
bug in the previous, so fetch it again.

christos