On Tue, 02 Feb 1999 00:02:44 +0100, Olaf Kirch <okir@monad.swb.de> said:
> What the code is currently(?) doing is checking whether the write goes
> to the same write as the last one. If so, we assume that there are more
> to come, and delay syncing the data for a bit. If the inode is still
> dirty after that, we call write_inode_now(). This _usually_ works,
> but it's in no way foolproof.
A mechanism I have used in the past to good effect is simply for the
server to defer the sync and ack until the incoming request queue is
empty or until the backlog of unsynced requests grows too large (for
some appropriate value of "too large": it might be only 3 or 4 requests
in this case).
As long as the client can keep data coming, we can keep buffering it,
until we reach the backlog limit and sync what we have. Until that
limit is reached, we can continue write-gathering, and as soon as we see
an empty incoming request queue we can sync/ack immediately before going
to sleep. For this to work well the backlog limit has to be smaller
than the limit on the number of outstanding page writes at once on the
client side.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/