Messages in this thread | | | Date | Thu, 29 Jul 1999 14:45:51 -0400 (EDT) | From | Chuck Lever <> | Subject | Re: clustering page-ins |
| |
On Mon, 26 Jul 1999, Stephen C. Tweedie wrote: > On Fri, 23 Jul 1999 15:21:50 -0400 (EDT), Chuck Lever <cel@monkey.org> > said: > > i've implemented a read-ahead algorithm for mmap, and it appears to be > > working pretty well for applications that mmap a file then stream data > > from it (like mpg123). now i have some "implementation detail" questions > > for the list. in no particular order: > > > + read-ahead is triggered half a cluster before the end of the > > previously read segment. is this too far in advance? > > I'd trigger it at the start of each cluster: much simpler, conceptually, > and it maximises the time you've got to do the IO in before the > application needs it.
that means i either have to special-case the first cluster or read two clusters for the first cluster. i'll think about this some more.
> > + after scheduling the next window, should filemap_nopage run the > > disk queue, like do_generic_file_readahead? > > Yes.
why doesn't the "no_cached_page" case in filemap_nopage run the disk queue after all the page reads are scheduled? does the logic expect that the wait_for_page/lock_page code to handle it?
> > + should the mmap read-ahead logic reuse the read-ahead context > > contained in the file struct, or should it maintain separate > > context in the vm_area struct? > > Use a separate context: mmap() activity should not have any affect on > the file stream that was mmaped.
true. but i'm also worried about sharing the read-ahead information amongst all mappers of a shared file. this case has come up in my benchmarking (although i haven't tracked it down, it is occurring in some basic commands that are run by the benchmark).
so, i think the information needs to be in the file struct so that shared maps don't continue to read ahead a file that is already in the page cache.
> > + what's a reasonable maximum window size? right now i've set it > > arbitrarily at 256K. would it be worth it to allow up to a megabyte > > per read-ahead? or maybe the maximum value should be parametrized > > to the size of physical memory, just like page_cluster? > > Use the device max_readahead[] table --- that's what it is there for. > The readahead table will automatically get set up with meaningful values > if you are running a striped raid device.
that value looks too small to me. we are trying to read ahead only mmaped files that are accessed strictly sequentially, so it seems like filemap_nopage can safely schedule more pages than the normal speculative file read-ahead case.
- Chuck Lever -- corporate: <chuckl@netscape.com> personal: <chucklever@netscape.net> or <cel@monkey.org>
The Linux Scalability project: http://www.citi.umich.edu/projects/linux-scalability/
- 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/
| |