On Tue, Feb 20, 2001 at 02:27:57PM +0100, Paul Kranenburg wrote:
> I should amend this. A process pacing itself by sleeping in request_cleanup()
> is woken up already after softdep_process_worklist() has run (once); fiddling
> with `tickdelay' probably isn't worth the effort anyway.
> 
> One further remark: since softdep worklist processing is handled by the
> syncer process entirely, there's a severe risk of context switch trashing
> when the worklist queue is allowed to hover around `max_softdep' threshold,
> in which case the syncer process will be doing "rush jobs" all the time.
> 
> There should probably be some "hysteresis loop" that forces enough
> worklist processing until the resource allocation is well below
> the designated maximum.

The only way to enforce the upper limit would be to check for it
before each dependency addition, and wait for it to drop if it's
too high. However, you may be holding some (vnode) locks at that
point, which the syncer might also want, also the upper loop
does check for locked vnodes.

Having softdep_process_worklist() just go on until it's below
the limit again would mostly work, then again, there's a risk
that you go through the roof before it gets to run (though
this might be mostly theoretical)

A recent change to the FreeBSD code makes dependency cleanups
also happen from other processes, with some additional hacks
to see if no deadlocks occur.

All methods seem a bit messy. I keep thinking "there must be
a better way to do all this", but that's easy to say, since
I haven't actually found a better method :-)

- Frank

-- 
Frank van der Linden                           fvdl@wasabisystems.com
======================================================================
Quality NetBSD CDs, Support & Service.   http://www.wasabisystems.com/