Messages in this thread |  | | | Date | Mon, 2 Aug 1999 15:50:36 -0400 (EDT) | | From | Chuck Lever <> | | Subject | Re: clustering page-ins |
| |
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/
|  |