> adapting `tickdelay' dynamically driven by resource usage, or by doing
> what everybody else does: sleeping on a channel to be woken up when the
> syncer has freed enough resources, i.e. from softdep_process_worklist().

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.

-pk