cvs commit: src/sys/kern vfs_subr.c src/sys/sys buf.h bufobj.h vnode.h

[Don Lewis]

On 27 Oct, Poul-Henning Kamp wrote:

> I am still not convinced that even having the generic syncer is a
> good idea.  I think it would make a lot more sense to park a kthread
> on each mountpoint to act as syncer for that mountpoint.  And then
> _maybe_ have a bufobj method that says "reduce your footprint" in
> some sort of way to keep the global balance.

I think this idea has a lot of merit.  The per-mountpoint syncer would
probably still want to track things at the vnode level so that it could
coordinate syncing the underlying bufobjs and inodes.  Different mount
points (and non-filesystem syncers) might want to use different sync
schedules.

In this case, it might make sense to back out the changes to
sched_sync() and friends and instead add a bufobj syncer thread that
handles bufobjs that are not associated with vnodes.

It might also make sense to have a bufobj syncer and an inode syncer,
which would have the advantage of balancing bufobj use, but coordination
between the two syncers would seem to be complicated.  I don't know how
much of an advantage of this is in practice, since the primary job of
the syncer isn't to reduce memory pressure, but to make sure that data
is flushed to stable storage in a reasonable amount of time.  We already
have other ways of reclaiming memory when resources are tight.

If you continue on your current path, I'd like the ability to put
"empty" or clean bufobjs that reference vnodes on the work list.