[lkml]   [1999]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: clustering page-ins
On Tue, 20 Jul 1999, Rik van Riel wrote:
> > as jamie says, it's easy to recognize strict monotonically
> > increasing sequential access to pages and aggressively read ahead
> > in that case.
> OK. Then I guess we want to implement this for mmap() and
> swap I/O.

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?

+ after scheduling the next window, should filemap_nopage run the
disk queue, like do_generic_file_readahead?

+ 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?

+ 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.

+ 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?

- 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.074 / U:43.552 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site