On Tue, Sep 03, 2002 at 10:05:59PM -0700, Chuck Silvers wrote:
> hi,
> 
> as you allude to, the i/os sent from the FS/VM layer to the disk driver
> will already have clustering done, so there's little to be gained by
> doing it again in the disk driver.  the exception to this would be for
> layered disk drivers like raidframe, where non-contiguous chunks of i/o
> in the virtual device presented to the FS/VM layer can become contiguous
> for the underlying real devices.  for such layered disk drivers, this
> re-clustering could potentially be useful.  I'd like to see some
> empirical evidence that such code helps before it went into the tree, though.

It's trivial to see that this helps RAIDframe; the FS layer will only cluster
to MAXPHYS, which RAIDframe has to split up again, so that it is, in fact,
impossible to get a MAXPHYS-sized transfer out of RAIDframe.  It takes only
minutes to set up a RAIDframe configuration such that you can demonstrate for
yourself that the large number of transfers this generates is a serious issue
for disk performance.

Also, this will catch asynchronous transfers that were not contiguous when
issued (and thus couldn't be clustered) but for which neighbors exist when
they're dequeued.  Workloads with multiple writers can generate those even
with the UBC clustering, it seems to me.

Thor