Re: CVS commit: [tls-maxphys] src/sys/dev

[Chuck Silvers <chuq%chuq.com@localhost>]

On Tue, Oct 09, 2012 at 11:24:13AM -0400, Thor Lancelot Simon wrote:
> On Tue, Oct 09, 2012 at 05:21:17PM +0200, Manuel Bouyer wrote:
> > On Tue, Oct 09, 2012 at 11:04:20AM -0400, Thor Lancelot Simon wrote:
> > > Hmmmmm.
> > > 
> > > This will be an attempt to transfer an entire file -- 139264 will be the
> > > entire file size of something, probably an executable it's paging in.
> > > 
> > > I saw this before -- I can't remember what caused it -- the "bad 
> > > chunksize"
> > > is, I think, because it's not power-of-2.  The cause will be in the UVM
> > > readahead code.
> > 
> > It is. It looks like this code is different in tls-maxphys and HEAD.
> 
> Is it different in tls-maxphys-base and HEAD?  I played with this code
> quite a bit while debugging previously, I believe.
> 
> > I wonder if we really want to read in power-of-2 chunks here, or just
> > multiple of page size. Reading the code which calls ra_startio(),
> > I'm not sure why size of chunksize would be a power-of-2.
> 
> I wondered that myself.  I think multiple of pagesize is probably okay,
> but -- IIRC -- I couldn't convince myself we'd always do the right thing
> with the residual.  Try it?

the underlying mechanism used by the UVM read ahead code (pgo_get / 
VOP_GETPAGES)
can handle any number of pages, not just power-of-2-sized groups of pages.
there's no reason for the read ahead code to limit itself that way.

-Chuck