Re: clustering page-ins
Chuck Lever (cel@monkey.org)
Mon, 2 Aug 1999 15:50:36 -0400 (EDT)
On Fri, 30 Jul 1999, Stephen C. Tweedie wrote:
> On Thu, 29 Jul 1999 14:55:17 -0400 (EDT), Chuck Lever <cel@monkey.org>
> said:
>
> > right, i agree. the read-ahead logic i'm adding only works for strictly
> > sequentially accessed pages to catch the case where an application mmaps a
> > file and "streams" it (a la grep or mpg123). in that case, it seems safe
> > to unreference the pages behind the current faulting page since we're
> > fairly certain that the application won't be going back.
>
> No, we aren't. The tiled access pattern is a good example: the input
> from the file is *entirely* streamed. As long as we can hold one or two
> tiles in memory, all access to data on disk is purely, 100% sequential.
> It makes no sense to have the readahead optimisations not work in this
> case.
>
> Consider also an application which mmaps a data file and performs
> several sequential passes over that memory. Unmapping pages behind the
> fault will just cause huge amounts of totally unnecessary page table
> activity when we perform the next pass over the data, and remember, page
> table modifications are really expensive on threaded SMP tasks.
ok, i may have missed something, but i'm not talking about unmapping.
all i want to do is "unreference" these pages -- simply clear the
reference bit. if there is no memory pressure, nothing else will happen.
> > and, unreferencing doesn't take the page out of the page cache, it
> > simply makes it more likely to be reaped by shrink_mmap. so this is
> > only an issue during periods when memory is low.
>
> Exactly. The real solution is to have dynamic RSS limits --- if, and
> only if, the page fault will cause us to exceed the dynamic RSS limit,
> we'll do an unfault-behind.
a max-rss is already maintained (via get/setrlimit). are you thinking of
some other value that could be computed by the VM system?
- 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/