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

    \
     
     \ /
      Last update: 2005-03-22 13:53    [W:0.021 / U:3.308 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site