linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Friesen <cfriesen@nortelnetworks.com>
To: Mark Mielke <mark@mark.mielke.cc>
Cc: Helge Hafting <helgehaf@aitel.hist.no>,
	Thomas Schlichter <schlicht@rumms.uni-mannheim.de>,
	linux-kernel@vger.kernel.org
Subject: Re: An idea for prefetching swapped memory...
Date: Mon, 07 Apr 2003 14:49:10 -0400	[thread overview]
Message-ID: <3E91C826.8000806@nortelnetworks.com> (raw)
In-Reply-To: 20030407183700.GB7311@mark.mielke.cc

Mark Mielke wrote:
> On Mon, Apr 07, 2003 at 10:19:25AM -0400, Chris Friesen wrote:

> Chris: Based on your usage patterns, how would Linux know that you were
> going to be opening up Mozilla, and not that you were going to tweak the
> kernel source and compile it again?

Because it would read my mind and figure out what I wanted!   ;-)

Maybe it would be possible to have some way to tell the kernel, "I would prefer 
this process to be in memory, unless you're running short, at which point you 
can swap it out."

This would be very similar to the niceness value, except it would control what 
memory gets swapped out.  You could tie it in to what processes have been 
running, such that if the system goes idle you could start preferentially 
swapping back in the processes with the memory niceness set.  If you left it at 
zero you get the current behaviour (not swapped in until needed) while positive 
(or negative, to align with niceness) values would swap that process in 
preferentially when the system goes idle.

This would give similar benefits as mlock without actually robbing the kernel of 
the ability to swap out under memory pressure.

Does this sound at all useful, or am I blowing smoke?

Chris



-- 
Chris Friesen                    | MailStop: 043/33/F10
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com


  reply	other threads:[~2003-04-07 18:37 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
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 [this message]
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=3E91C826.8000806@nortelnetworks.com \
    --to=cfriesen@nortelnetworks.com \
    --cc=helgehaf@aitel.hist.no \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark@mark.mielke.cc \
    --cc=schlicht@rumms.uni-mannheim.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).