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/