linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Bradford <john@grabjohn.com>
To: zwane@linuxpower.ca (Zwane Mwaikambo)
Cc: john@grabjohn.com (John Bradford),
	schlicht@uni-mannheim.de (Thomas Schlichter),
	akpm@digeo.com (Andrew Morton),
	linux-kernel@vger.kernel.org
Subject: Re: [RFC] first try for swap prefetch
Date: Fri, 11 Apr 2003 14:29:23 +0100 (BST)	[thread overview]
Message-ID: <200304111329.h3BDTN1P000878@81-2-122-30.bradfords.org.uk> (raw)
In-Reply-To: <Pine.LNX.4.50.0304110819180.540-100000@montezuma.mastecende.com> from "Zwane Mwaikambo" at Apr 11, 2003 08:22:27 AM

> > Actually, it could potentially do something very useful - if you are
> > using a laptop, or other machine where disks are spun down to save
> > power, you might be swapping in data while the disk still happens to
> > be spinning, rather than letting it spin down, then having to spin it
> > up again - in that instance you are definitely gaining something,
> > (more battery life).
> 
> That sounds like a rather short disk spin down time (in which case you 
> might not be gaining all that much battery life given the constant spin 
> up/down), either that or you're paging in way too much stuff.

Sure, it's probably not going to happen with normal usage, but say
you're using a large application, then load a web browser to read the
documentaion, and part of the large application is swapped out.  Once
the web browser has loaded, it might free some RAM, and then you spend
10 minutes reading the documentation.  The disk might spin down after
five minutes, and then have to spin back up again when you switch back
to your main application.  We could possibly avoid this by swapping
the pages back in after one minute of inactivity, then letting the
disk spin down.

Infact, we could spin down the disk _immediately_, if we find that we
can swap all of the pages back in to physical RAM.  Of course, that
would only make sense if the disk is being used primarily for swap,
but it's a scenario where we could do better than we are at the
moment.

John.

  reply	other threads:[~2003-04-11 13:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-10 17:47 [RFC] first try for swap prefetch Thomas Schlichter
2003-04-10 23:18 ` Andrew Morton
2003-04-11 11:51   ` Thomas Schlichter
2003-04-11 12:13     ` William Lee Irwin III
2003-04-11 12:21     ` John Bradford
2003-04-11 12:22       ` Zwane Mwaikambo
2003-04-11 13:29         ` John Bradford [this message]
2003-04-11 21:39     ` Andrew Morton
2003-04-12  5:05       ` Thomas Schlichter
2003-04-12  5:37         ` Andrew Morton
2003-04-17 16:02           ` [RFC] second try for swap prefetch (does Oops!) Thomas Schlichter
2003-04-11 16:57 [RFC] first try for swap prefetch Chuck Ebbert

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=200304111329.h3BDTN1P000878@81-2-122-30.bradfords.org.uk \
    --to=john@grabjohn.com \
    --cc=akpm@digeo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=schlicht@uni-mannheim.de \
    --cc=zwane@linuxpower.ca \
    /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).