On Sun, Feb 02, 2003 at 12:50:38PM -0800, Chuck Silvers wrote:
> hi,
> 
> what you're observing here is that the current genfs read ahead
> isn't terribly smart, which is true.  the previous read ahead code
> in the now-gone vfs_cluster.c was only slightly smarter, so the
> genfs stuff seemed good enough at the time.  it can certainly be
> improved, though.  a better way might be to use an adaptive approach
> similar to TCP's mechanism for adjusting the window size.

That's not the only issue, AFAICT.  The other issue is that aside from
the coincidence that it will likely get hit by the read-ahead, there's
basically nothing that respects the size of the user's I/O request. 
Without the read-ahead, if a user asked for 32K, we'd fault four times
and do four single-page reads -- when if we preserved the request size
the user asked for, there'd be no reason to do that.  Similarly, if we
eliminate MAXPHYS, if a user asks for 4MB, *even if the device can
deliver it*, we'll actually still read it in separate chunks of 
MAX_READ_AHEAD -- and clearly increasing MAX_READ_AHEAD to 4MB would
be a dumb thing to do.

I think the approach of using read-ahead to handle all explicit I/O
requests larger than a single page is highly questionable.  Isn't there
some way to make the actual I/O request size visible at this layer?

Thor