lkml.org 
[lkml]   [1999]   [Jul]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.136 / U:0.372 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site