Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Fri, 30 Jul 1999 01:09:25 +0100 (BST) | Subject | Re: clustering page-ins |
| |
Hi,
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.
> 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.
--Stephen
- 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/
| |