public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@zip.com.au>
To: Dave Jones <davej@codemonkey.org.uk>
Cc: "Randy.Dunlap" <rddunlap@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: [announce] swap mini-howto
Date: Fri, 01 Nov 2002 16:46:50 -0800	[thread overview]
Message-ID: <3DC3207A.450402B3@zip.com.au> (raw)
In-Reply-To: 20021102000907.GA9229@suse.de

Dave Jones wrote:
> 
> Might be nice to mention that using multiple swap partitions
> on different disks will 'stripe' requests across disks a-la-raid0
> 

Yup.

Something I'd like to point out here:  in 2.4 and earlier, swapfiles
are less robust than swap devices - the need to go and read metadata
from the filesystem made them prone to oom deadlocks allocating pages
and buffer_heads with which to perform the swapout.

That has changed in 2.5.  Swapping onto a regular file has no
disadvantage wrt swapping onto a block device.  The kernel does
not need to allocate any memory at all to get a swapcache page
onto disk.

Which is interesting.  Because swapfiles are much easier to administer,
and much easier to stripe.  Adding, removing and resizing is simplified.
Distributors of 2.6-based kernels could consider doing away with
swapdevs altogether.


If you have two disks then it is very sensible to create a swapfile on
each one and to perform an equal-priority stripe between them.  This
will give the best raw swap IO bandwidth.  But it could cause additional
seeking between swap and regular file data.

Dedicating an entire disk to swap will obviously reduce the seeking
problem.

But really, if your application is dependent on swap performance, you
need more RAM.  Swap should be viewed as a lightweight background
optimisation to make unused pages available for other work, rather
than as a cure for an underprovisioned machine.

  parent reply	other threads:[~2002-11-02  0:40 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-01 23:58 [announce] swap mini-howto Randy.Dunlap
2002-11-02  0:09 ` Dave Jones
2002-11-02  0:07   ` Randy.Dunlap
2002-11-02  0:46   ` Andrew Morton [this message]
2002-11-02  8:26     ` Jeff Garzik
2002-11-02 10:02       ` Andrew Morton
2002-11-02 23:31         ` Jeff Garzik
2002-11-02 11:22     ` Troels Walsted Hansen
2002-11-04 10:47       ` Richard Russon
2002-11-02 16:55     ` Pavel Machek
2002-11-02 21:23       ` Rik van Riel
2002-11-02 21:28         ` Pavel Machek
2002-11-02  0:19 ` Andries Brouwer
2002-11-02  0:25   ` Randy.Dunlap
2002-11-02 11:19     ` Andries Brouwer
2002-11-05  5:54       ` [announce] swap mini-howto (updated) Randy.Dunlap
2002-11-02  1:01 ` [announce] swap mini-howto Nicolas Pitre
2002-11-02  1:23 ` Bernd Eckenfels
  -- strict thread matches above, loose matches on Subject: below --
2002-11-03 10:56 Gabor MICSKO

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=3DC3207A.450402B3@zip.com.au \
    --to=akpm@zip.com.au \
    --cc=davej@codemonkey.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rddunlap@osdl.org \
    /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