Date: Thu, 17 Apr 2003 21:26:57 +0200 From: Marko Zec <zec@tel.fer.hr> To: Terry Lambert <tlambert2@mindspring.com> Cc: freebsd-stable@FreeBSD.org Subject: Re: PATCH: Forcible delaying of UFS (soft)updates Message-ID: <200304172126.57611.zec@tel.fer.hr> In-Reply-To: <3E9ED902.8BF30AA7@mindspring.com> References: <3E976EBD.C3E66EF8@tel.fer.hr> <3E9E93D8.EB16ED42@tel.fer.hr> <3E9ED902.8BF30AA7@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200304172126.57611.zec>