From owner-freebsd-stable@FreeBSD.ORG Thu Apr 17 12:27:13 2003 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F08D37B401; Thu, 17 Apr 2003 12:27:13 -0700 (PDT) Received: from mail.tel.fer.hr (zg07-196.dialin.iskon.hr [213.191.150.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 832FC43F3F; Thu, 17 Apr 2003 12:27:10 -0700 (PDT) (envelope-from zec@tel.fer.hr) Received: from marko-tp (marko@[192.168.202.105]) by mail.tel.fer.hr (8.12.6/8.12.6) with ESMTP id h3HJPFxI000836; Thu, 17 Apr 2003 21:25:20 +0200 (CEST) (envelope-from zec@tel.fer.hr) From: Marko Zec To: Terry Lambert Date: Thu, 17 Apr 2003 21:26:57 +0200 User-Agent: KMail/1.5 References: <3E976EBD.C3E66EF8@tel.fer.hr> <3E9E93D8.EB16ED42@tel.fer.hr> <3E9ED902.8BF30AA7@mindspring.com> In-Reply-To: <3E9ED902.8BF30AA7@mindspring.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200304172126.57611.zec@tel.fer.hr> cc: freebsd-fs@FreeBSD.org cc: David Schultz cc: freebsd-stable@FreeBSD.org Subject: Re: PATCH: Forcible delaying of UFS (soft)updates X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 19:27:13 -0000 On Thursday 17 April 2003 18:40, Terry Lambert wrote: > Marko Zec wrote: > > David Schultz wrote: > > > I was referring to all the places where rushjob is set to or > > > incremented by syncer_maxdelay. AFAIK, it should never be that > > > large. > > > > Hmm... Why? :) > > Increased latency; larger pool retention time, larger pool size, > more kernel memory tied up in dependency lists for longer, more > operations blocked because a dependency is already on the write > list, and so locked against modification. Increasing "rushjob" has only a single consequence, and that is precisely a prompt flushing of dirty buffers. Are you sure we are talking about the same code here, rushjob in kern/vfs_subr.c, or something completely different? > > > > I don't think you want to overload a low memory handling > > > mechanism with the task of syncing the disk. > > > > As far as I can see the rushjob variable is used only at one place in > > kern/vfs_subr.c to notify softupdates synching scheduler to start > > synching earlier than the normal timers would expire. I just reused > > the same mechanism to urge synching of dirty buffers when the extra > > delay timer expires, or when outstanding disk I/O occurs, to coalesce > > disk updates with occasional disk spinups. > > ...and not syncing in the normal place. > > I'm wondering if this really helps some real world situation; > my gut feeling is that it doesn't, and it increases memory use > considerably, until it's flushed. Ignoring fsync _really_ helps in real world situations, if you keep in mind that the original purpose of the patch is to keep the disk spinned down and save battery power. > > What I'd like to see is a statistics counter of "delayed syncs" > that occur as a result of doing this, gathered over a period of > time, along with another statistics counter of "drive spindowns". > > I know that this will probably end up being observer influenced > enough to be merely anecdotal, but say gather two sets over an > extended period of use without powering the machine down; the > first set without the change, and the next set with the change. > > Either way it turns out, it would make a stronger case for or > against than just hand-waving. 8-). Such a measurement could turn out to be relevant only if one would precisely define a test load. Obviously different results could be expected if the machine would be completely idle and if it would be not. Instead of just hand-waving, could we just more closely specify what we consider a relevant load for a battery-powered laptop? :) Marko