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