From owner-cvs-src@FreeBSD.ORG Wed Oct 27 10:20:02 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0B9316A4CE; Wed, 27 Oct 2004 10:20:02 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8813A43D3F; Wed, 27 Oct 2004 10:20:02 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id i9RAJqTi020328; Wed, 27 Oct 2004 03:19:57 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200410271019.i9RAJqTi020328@gw.catspoiler.org> Date: Wed, 27 Oct 2004 03:19:52 -0700 (PDT) From: Don Lewis To: phk@phk.freebsd.dk In-Reply-To: <68118.1098869813@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern vfs_subr.c src/sys/sys buf.h bufobj.h vnode.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2004 10:20:03 -0000 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.