Dag-Erling Smorgrav <firstname.lastname@example.org> writes:
> Somebody on IRC suggested changing ffs_sync() to traverse the synclist
> instead of the mountpoint's vnode list, and just comparing v_mount to
> mp and ignoring vnodes that aren't "ours". It would work, but gives
> me goosebumps for some reason.
Another possibility, of course, is to have ffs_sync() simply check if
the vnode is on a worklist (v_flags & VONWORKLIST != 0) but that
requires acquiring the vnode interlock, so we gain nothing.
> All of this only solves part of the problem, though - the ffs_sync()
> part - there's still something screwy with sched_sync(), but I'll need
> to acquite more profiling data to figure out just *what*.
Actually, there's nothing screwy about sched_sync(), except that I
overlooked the fact that it calls sync_fsync() (through VOP_FSYNC())
which calls ffs_sync(). Judging from collected stats, I'm wondering
if there's really any point in calling ffs_sync() (indirectly) from
sched_sync(), as it seems to rarely actually *do* much except screw up
my interrupt latency. I guess it's useful as a safety net, but I
don't really see how a vnode can be dirty and not on the sync list?
Ditching the syncer nodes will also (finally) allow FreeBSD laptops to
let their disks spin down when idle...
Dag-Erling Smorgrav - email@example.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message