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

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.066 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site