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

    > > + 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: <>
    personal: <> or <>

    The Linux Scalability project:

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:53    [W:0.023 / U:4.568 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site