From owner-freebsd-arch Mon Feb 10 1:50:44 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7EE5A37B401 for ; Mon, 10 Feb 2003 01:50:42 -0800 (PST) Received: from HAL9000.homeunix.com (12-233-57-224.client.attbi.com [12.233.57.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1C1343F75 for ; Mon, 10 Feb 2003 01:50:41 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id h1A9oeoH005612; Mon, 10 Feb 2003 01:50:40 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id h1A9oeIH005611; Mon, 10 Feb 2003 01:50:40 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Mon, 10 Feb 2003 01:50:40 -0800 From: David Schultz To: phk@phk.freebsd.dk Cc: arch@FreeBSD.ORG Subject: Re: Our lemming-syncer caught in the act. Message-ID: <20030210095040.GB5515@HAL9000.homeunix.com> Mail-Followup-To: phk@phk.freebsd.dk, arch@FreeBSD.ORG References: <20030210091317.GD5165@HAL9000.homeunix.com> <37473.1044868995@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37473.1044868995@critter.freebsd.dk> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thus spake phk@phk.freebsd.dk : > In message <20030210091317.GD5165@HAL9000.homeunix.com>, David Schultz writes: > > >When a large file times out, a significant amount of I/O can be > >generated. This is still far better than the old syncer that > >flushed everything every 30 seconds. The reasons for this > >behavior are explained in src/sys/ufs/ffs/README. After reading > >that, do you still think it makes sense to try to do better? > > Yes, it makes a lot of sense. There is no point in batching up > writes to the point of showing 200 requests off at once then > wait 30 seconds, then do it again etc etc. > > We can and need to do better than that. It sounds like you're describing the old syncer. The new one still shoves groups of buffers out at once, but on a file-by-file basis rather than globally every 30 seconds. (Maybe that's what you meant.) To fix the problem correctly, you would probably need to track the timeouts on each individual buffer and pay the extra management overhead. Alternatively, perhaps it would be possible to ``pace'' files that have large numbers of dirty buffers associated with them. You could extend softdep_fsync() by adding an additional argument specifying the maximum number of buffers to write, so that when a large file times out, it can be staggered over several runs of the syncer (which is activated every second.) Kirk would be a good person to talk to, I think. By the way, can you see what effect lowering the following sysctls has? John Dyson reported that the default timeouts are well into diminishing returns for improving performance, and a few months ago I actually saw a small but measurable performance *increase* with the values below: kern.filedelay: 7 kern.dirdelay: 6 kern.metadelay: 5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message