:> driver, but it's also possible that they are due to a bug in the
:> buffer cache flushing code which the following patch fixes. So try
:> the patch and see if that fixes your problem. If it doesn't then
:> we can at least rule it out as being the cause of the problem you
:> are seeing.
:[..]
:
:Just one comment.. You've replaced vfs_bio's call to speedup_syncer() with
:a bufdaemon speedup.. Granted I don't understand the details here, but
:I'm curious why? (or why not use both?) The reason I ask is that I wonder
:whether removing of the speedup of the vnode cleanup rate is a good idea or
:not.. or if the bufdaemon speedup does this as a side effect via the hooks
:softupdates has got in the bio system. This is not a criticism, just a
:request for enlightenment. :-)
speedup_syncer() was designed for softupdates to allow softupdates to
regulate the number of pending transactions. The problem with it,
though, is that calling the function results in a 'slow reaction' by
the system rather then an 'immediate reaction', and in this particular
case we need an immediate reaction. A slow reaction gets us nowhere
(gets us multi-second delays, in fact).
bd_speedup() wakes up the buf_daemon and as part of the patch the
buf_daemon has been redesigned to handle the 'immediate reaction' case
without compromising its dynamic stability characteristics (which are
what tend to make it efficient under normal operation).
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
:
:> @@ -1571,9 +1573,8 @@
:> flags = VFS_BIO_NEED_ANY;
:> }
:>
:> - /* XXX */
:> + bd_speedup(); /* heeeelp */
:>
:> - (void) speedup_syncer();
:> needsbuffer |= flags;
:> while (needsbuffer & flags) {
:> if (tsleep(&needsbuffer, (PRIBIO + 4) | slpflag,
:
:Cheers,
:-Peter
:
:
:
:
:To Unsubscribe: send mail to [EMAIL PROTECTED]
:with "unsubscribe freebsd-current" in the body of the message
:
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
