PATCH: Forcible delaying of UFS (soft)updates

[Terry Lambert]

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.


> > 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.

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-).

-- Terry