Re: serious performance regression in .41

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

   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.