Date: Wed, 27 Oct 2004 03:19:52 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: phk@phk.freebsd.dk Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern vfs_subr.c src/sys/sys buf.h bufobj.h vnode.h Message-ID: <200410271019.i9RAJqTi020328@gw.catspoiler.org> In-Reply-To: <68118.1098869813@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200410271019.i9RAJqTi020328>