All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Mielke <mark@mark.mielke.cc>
To: "Måns Rullgård" <mru@users.sourceforge.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: An idea for prefetching swapped memory...
Date: Mon, 7 Apr 2003 14:33:52 -0400	[thread overview]
Message-ID: <20030407183352.GA7311@mark.mielke.cc> (raw)
In-Reply-To: <yw1xsmsuk0sm.fsf@nogger.e.kth.se>

On Mon, Apr 07, 2003 at 01:24:41PM +0200, M?ns Rullg?rd wrote:
> Thomas Schlichter <schlicht@rumms.uni-mannheim.de> writes:
> > > This has been argued before. Why would the last swapped out pages
> > > be the best to swap in? The vm subsystem has (somehow) decided
> > > they're the least likely to be used again so why swap them in?
> > > Alternatively how would it know which to swap in instead?  Con

> > What I wanted to say is that if there is free memory it should be
> > filled with the pages that were in use before the memory got
> > rare. And these are the pages swapped out last. The other swapped
> > out pages are swapped out even longer and so will likely not be used
> > in the near future... (That's what the LRU algorithm says...)

> Would it be possible to track the most recently used swapped out page?
> This would possibly be a good candidate for speculative loading.

Personally, I'm not sure that this idea sounds very effective. I
_like_ the fact that after pages get swapped out, my RAM gets filled
up with file pages with use. It means that although bringing a window
that I haven't used in a while takes some time to load, my apache
server, or my xterm, can serve files or requests like 'ls' much
faster. If swap was automatically pulled in to replace my file pages,
I suspect I would be trading one evil for another.

mark

-- 
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/


  parent reply	other threads:[~2003-04-07 18:15 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-07  8:26 An idea for prefetching swapped memory Thomas Schlichter
2003-04-07 10:21 ` Con Kolivas
2003-04-07 10:47   ` Thomas Schlichter
2003-04-07 11:24     ` Måns Rullgård
2003-04-07 12:46       ` Thomas Schlichter
2003-04-07 18:33       ` Mark Mielke [this message]
2003-04-07 13:24     ` Helge Hafting
2003-04-07 14:19       ` Chris Friesen
2003-04-07 14:39         ` Jörn Engel
2003-04-07 18:37         ` Mark Mielke
2003-04-07 18:49           ` Chris Friesen
2003-04-07 19:35             ` Mark Mielke
2003-04-07 19:39             ` Robert White
2003-04-07 20:44               ` Chris Friesen
2003-04-07 11:36   ` Christophe Saout
2003-04-07 11:48     ` Måns Rullgård
2003-04-07 12:19       ` Jörn Engel
2003-04-07 12:45         ` Christophe Saout
2003-04-07 16:30   ` Magnus Danielson
2003-04-07 12:32 ` David Zaffiro
2003-04-07 12:43   ` Jörn Engel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030407183352.GA7311@mark.mielke.cc \
    --to=mark@mark.mielke.cc \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mru@users.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.