lkml.org 
[lkml]   [2001]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: VM Requirement Document - v0.0
    On Mon, 2 Jul 2001, Rik van Riel wrote:

    > On Thu, 28 Jun 2001, Marco Colombo wrote:
    >
    > > I'm not sure that, in general, recent pages with only one access are
    > > still better eviction candidates compared to 8 hours old pages. Here
    > > we need either another way to detect one-shot activity (like the one
    > > performed by updatedb),
    >
    > Fully agreed, but there is one problem with this idea.
    > Suppose you have a maximum of 20% of your RAM for these
    > "one-shot" things, now how are you going to be able to
    > page in an application with a working set of, say, 25%
    > the size of RAM ?
    >
    > If you don't have any special measures, the pages from
    > this "new" application will always be treated as one-shot
    > pages and the process will never be able to be cached in
    > memory completely...

    I see your point. Running Gnome on a 64MB box means you have most
    of the pages that are "warm" (using my definition), so there's little
    room for "cold" (new) pages, and maybe they don't get a chance of
    being accessed a second time before they are evicted, which leads to
    thrashing if you're trying to start something really big (well, I guess
    the access pattern within a typical ws is not uniformly distributed, so
    some pages will get accessed twice, but I see the problem).

    I'll try and make my point a bit clearer.
    I was referring to background aging only. When aging
    is caused by pressure, you don't make any difference between pages.
    I don't know how the idea to give high values for page->age on the second
    access instead of the first is going to be implemented, but I'm assuming
    that new pages are going to be placed on the active list with a low age
    value (PAGE_AGE_START_FIRST ?), maybe even 0 (well, I'm not a guru of
    course). I'm just saying that, to avoid Mike's "problem" (which BTW
    I don't believe is a big one, really), we could stop background aging
    on interactive pages (short form for "pages that belong to the ws of an
    interactive process") at a certain miminum age, say
    PAGE_AGE_BG_INTERACTIVE_MINIMUM, with PAGE_AGE_BG_INTERACTIVE_MINIMUM
    > PAGE_AGE_START_FIRST). Weighting the difference between the two
    ages, you can give long-standing interactive pages some advantage vs
    new pages. But they will be aged below PAGE_AGE_START_FIRST and eventually
    moved to the inactive list. After all, they *are* good candidates.
    Does this make some sense?

    Oh, yes, since that PAGE_AGE_BG_INTERACTIVE_MINIMUM is applied only
    when background aging, maybe it's not enough to keep processes like
    updatedb from causing interactive pages to be evicted.
    That's why I said we should have another way to detect that kind of
    activity... well, the application could just let us know (no need to
    embed an autotuning-genetic-page-replacement-optimizer into the kernel).
    We should just drop all FS metadata accessed by updatedb, since we
    know that's one-shot only, without raising pressure at all. Just like
    (not that I'm proposing it) putting those "one-shot" pages directly on
    the inactive-clean list instead of the active list. How an application
    could declare such a behaviour is an open question, of course. Maybe it's
    even possible to detect it. And BTW that's really fine tuning.
    Evicting an 8 hours old page may be a mistake sometime, but it's never
    a *big* mistake.

    >
    > Rik
    > --
    > Virtual memory is like a game you can't win;
    > However, without VM there's truly nothing to lose...
    >
    > http://www.surriel.com/ http://distro.conectiva.com/
    >
    > Send all your spam to aardvark@nl.linux.org (spam digging piggy)

    .TM.
    --
    ____/ ____/ /
    / / / Marco Colombo
    ___/ ___ / / Technical Manager
    / / / ESI s.r.l.
    _____/ _____/ _/ Colombo@ESI.it



    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 12:55    [W:0.025 / U:60.076 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site