linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Rik van Riel <H.H.vanRiel@phys.uu.nl>
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: jfm2@club-internet.fr, Linux MM <linux-mm@kvack.org>
Subject: Re: Two naive questions and a suggestion
Date: Thu, 26 Nov 1998 08:30:20 +0100 (CET)	[thread overview]
Message-ID: <Pine.LNX.3.96.981126082011.24048K-100000@mirkwood.dummy.home> (raw)
In-Reply-To: <199811252229.WAA05737@dax.scot.redhat.com>

On Wed, 25 Nov 1998, Stephen C. Tweedie wrote:
> On Wed, 25 Nov 1998 22:21:43 +0100 (CET), Rik van Riel
> <H.H.vanRiel@phys.uu.nl> said:
> 
> > Then I think it's time to do swapin readahead on the
> > entire SWAP_CLUSTER
> 
> Yep, although I'm not sure that reading a whole SWAP_CLUSTER would
> be a good idea.  Contrary to popular belief, disks are still quite
> slow at sequential data transfer.

I have a better idea for a default limit:
	swap_stream.max = num_physpages >> 9;
	if (swap_stream.max > SWAP_CLUSTER_MAX)
		swap_stream.max = SWAP_CLUSTER_MAX;
	swap_stream.enabled = 0;

> Non-sequential IO is obviously enormously slower still, but doing
> readahead on a whole SWAP_CLUSTER (128k) is definitely _not_ free. 
> It will increase the VM latency enormously if we start reading in a
> lot of unnecessary data. 

We could simply increase the readahead if we were more
than 50% succesful (ie. 80% of swap requests can be
satisfied from the swap cache) and decrease it if we
drop below 40% (or less than 50% of swap requests can
be serviced from the swap cache).

One thing that helps us enormously is the way kswapd
pages out stuff. If pages (within a process) have the
same kind of usage pattern and are near eachother, they
will be swapped out together. Now since they have the
same usage pattern, it is likely that they are needed
together as well.

Especially without page aging we are likely to store
adjecant pages next to eachother in swap.

Later on (when the simple code has been proven to
work and Linus doesn't pay attention) we can introduce
a really intelligent swapin readahead mechanism that
will make Linux rock :)

It's just that we need something simple now because
Linus wants the kernel to stay relatively unchanged
at the moment...

cheers,

Rik -- slowly getting used to dvorak kbd layout...
+-------------------------------------------------------------------+
| Linux memory management tour guide.        H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader.      http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+

--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

  reply	other threads:[~1998-11-26  7:35 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-11-19  0:20 jfm2
1998-11-19 20:05 ` Rik van Riel
1998-11-20  1:25   ` jfm2
1998-11-20 15:31     ` Eric W. Biederman
1998-11-23 18:08 ` Stephen C. Tweedie
1998-11-23 20:45   ` jfm2
1998-11-23 21:59   ` jfm2
1998-11-24  1:21     ` Vladimir Dergachev
1998-11-24 11:17     ` Stephen C. Tweedie
1998-11-24 21:44       ` jfm2
1998-11-25  6:41         ` Rik van Riel
1998-11-25 12:27           ` Stephen C. Tweedie
1998-11-25 13:08             ` Rik van Riel
1998-11-25 14:46               ` Stephen C. Tweedie
1998-11-25 16:47                 ` Rik van Riel
1998-11-25 21:02                   ` Stephen C. Tweedie
1998-11-25 21:21                     ` Rik van Riel
1998-11-25 22:29                       ` Stephen C. Tweedie
1998-11-26  7:30                         ` Rik van Riel [this message]
1998-11-26 12:48                           ` Stephen C. Tweedie
1998-11-25 20:01           ` jfm2
1998-11-26  7:16             ` Rik van Riel
1998-11-26 19:59               ` jfm2
1998-11-27 17:45                 ` Stephen C. Tweedie
1998-11-27 21:14                   ` jfm2
1998-11-25 14:48         ` Eric W. Biederman
1998-11-25 20:29           ` jfm2
1998-11-25 16:31         ` ralf
1998-11-26 12:18           ` Rik van Riel

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=Pine.LNX.3.96.981126082011.24048K-100000@mirkwood.dummy.home \
    --to=h.h.vanriel@phys.uu.nl \
    --cc=jfm2@club-internet.fr \
    --cc=linux-mm@kvack.org \
    --cc=sct@redhat.com \
    /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