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.
> + after scheduling the next window, should filemap_nopage run the
> disk queue, like do_generic_file_readahead?
Yes.
> + 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.
> + should this logic be overly concerned about protecting the
> read-ahead context from race conditions? a race condition
> is more probable here than in do_generic_file_readahead
> because this code handles shared memory areas.
The do_generic_file_readahead code has to deal with threads: you can
still have two processes owning a struct file *. So yes, be correct
when you have threads, but don't worry enormously about being fast.
Readahead is almost by definition only meaningful when there is only on
accessor at a time.
> + 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.
--Stephen
-
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/