From: Charles Marslett <cmarslett9@cs.com>
To: "J.A. Magallon" <jamagallon@able.es>
Cc: James A Sutherland <jas88@cam.ac.uk>, war <war@starband.net>,
linux-kernel@vger.kernel.org
Subject: Re: Swap
Date: Sun, 18 Nov 2001 15:36:41 -0700 [thread overview]
Message-ID: <3BF837F9.C7424E5C@cs.com> (raw)
In-Reply-To: <3BF82443.5D3E2E11@starband.net> <E165ZRi-000718-00@mauve.csi.cam.ac.uk> <20011118230540.A2042@werewolf.able.es>
"J.A. Magallon" wrote:
> On 20011118 James A Sutherland wrote:
> >On Sunday 18 November 2001 9:12 pm, war wrote:
> >> It is amazing that I could run all of that stuff, because:
> >>
> >> When I have swap on, and if I run all of those programs, 200-400MB of
> >> swap is used.
> >
> >Yep. There's a reason for that: the kernel is *ALWAYS* able to swap pages out
> >to disk - even without "swap space". Disabling swapspace simply forces the
> >kernel to swap out more code, since it cannot swap out any data.
>
> Sure ??? Where ?? What disk space uses it to swap pages to ?
The code is "swapped" to the original file it was loaded from. You just
free up the pages for someone else to use until you get a page fault in that
task, then reload it from the original executable. That may have something
to do with the fact that he gets better performance without a swap file allocated,
since code swaps never write, only read (half as much disk I/O). I could see
some workloads that essentially use every bit of data all the time, and swapping
code only is an optimization. Nothing I've ever profiled worked that way,
though. And I thought even in this case the system would tend to swap code
in preference to dirty data (I have to go back and look at the code to say
for sure, though).
> >(This is why you can still get "disk thrashing" without any swap - in fact,
> >it's more likely in this case than it is with some swap added - you are just
> >forcing your binaries to take more of the swapping load instead.)
> >
>
> You get thrashing because you don have anything cached. So you can get a point
> (fill all your space with apps and data) where each file read is _REALLY_ a
> disk read, not just a transfer from cache (that is what usually happens).
But that would never run faster than enabling the cache (unless the cache code
was competitive with Microsoft's).
> >So: with swapspace, the kernel swaps out a few hundred Mb of unused data, to
> >make room for more code. Without it, the kernel is forced to swap out code
> >pages instead. The big news here is...?
> >
>
> You swap out pages, not data or code. Kernel does not care if the page contains
> code or data. Try (on a swap enabled box) this: open mozilla or staroffice (a
> big gui app), let it open and don't use it, fill your ram with other apps and
> try to pull down a menu from mozilla. It has an unusual delay, the time to get
> mozilla CODE pages back from swap. That is why a system with no swap is more
> responsive.
Check out the thread entitled "Executing binaries on new filesystem" -- they talk
quite a bit about mmap() and how it is used in loading code space. You are right
about swapping out pages, not data or code, but the pages are written only if
they are dirty. A page that is not dirty does not need to be written to be swapped
out, and code pages are almost never dirty (I think). So they can be "swapped" out
without any place to write them, unlike data pages that have anything but zeros
in them.
> Yes, a box without swap runs faster, but if you *don't do anything* with it. The test
> shown in previous mails had a ton of apps opened *doing nothing*. Try do do
> a grep several times on the kernel source tree for example in that scenario.
> Or a kernel build. They will be dog slow (all the tries). Try the same on
> a box with swap, the second time much things are cached and it flies.
Ah! This may well be the explanation for the apparent performance boost. Now I'm
really interested in digging into the paging algorithms....
> --
> J.A. Magallon # Let the source be with you...
> mailto:jamagallon@able.es
> Mandrake Linux release 8.2 (Cooker) for i586
> Linux werewolf 2.4.15-pre6-beo #1 SMP Sun Nov 18 10:25:01 CET 2001 i686
--Charles
next prev parent reply other threads:[~2001-11-18 22:38 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-18 21:12 Swap war
2001-11-18 21:25 ` Swap James A Sutherland
2001-11-18 21:28 ` Swap war
2001-11-18 21:42 ` Swap François Cami
2001-11-18 21:45 ` Swap war
2001-11-18 23:03 ` Swap Erik Gustavsson
2001-11-19 18:12 ` Swap Eric W. Biederman
2001-11-19 18:43 ` Swap Rik van Riel
2001-11-20 2:49 ` Swap Eric W. Biederman
2001-11-20 3:33 ` Swap Ryan Cumming
2001-11-20 11:43 ` Swap Rik van Riel
2001-11-20 11:41 ` Swap Rik van Riel
2001-11-19 19:12 ` Swap James A Sutherland
2001-11-20 2:47 ` Swap Eric W. Biederman
2001-11-20 9:16 ` Swap James A Sutherland
2001-11-18 22:05 ` Swap J.A. Magallon
2001-11-18 22:21 ` Swap François Cami
2001-11-18 22:36 ` Charles Marslett [this message]
2001-11-18 22:54 ` Swap J.A. Magallon
2001-11-18 23:36 ` Swap Bernd Eckenfels
[not found] <fa.inl6g6v.1mmbp4@ifi.uio.no>
[not found] ` <fa.heevhav.sjs8an@ifi.uio.no>
2001-11-18 22:15 ` Swap Dan Maas
2001-11-18 22:43 ` Swap François Cami
2001-11-19 9:18 ` Swap James A Sutherland
2001-11-19 10:51 ` Swap Remco Post
2001-11-19 13:33 ` Swap James A Sutherland
2001-11-19 13:46 ` Swap Remco Post
2001-11-19 16:58 ` Swap Rik van Riel
[not found] ` <Pine.LNX.4.33L.0111191458150.1491-100000@duckman.distro.conecti va>
2001-11-19 21:13 ` Swap Alex Bligh - linux-kernel
2001-11-19 21:17 ` Swap Rik van Riel
[not found] ` <Pine.LNX.4.33L.0111191917000.1491-100000@duckman.distro.conecti va>
2001-11-19 21:52 ` Swap Alex Bligh - linux-kernel
2001-11-19 16:36 ` Swap Jesse Pollard
2001-11-20 14:51 ` Swap J.A. Magallon
2001-11-20 16:01 ` Swap Wolfgang Rohdewald
2001-11-20 16:06 ` Swap Remco Post
2001-11-20 16:12 ` Swap Nick LeRoy
2001-11-20 16:20 ` Swap Richard B. Johnson
2001-11-20 17:14 ` Swap Christopher Friesen
2001-11-20 17:40 ` Swap Richard B. Johnson
2001-11-20 18:14 ` Swap Nick LeRoy
2001-11-21 10:17 ` Swap Helge Hafting
2001-11-21 11:17 ` Swap Alan Cox
2001-11-20 23:20 ` Swap Luigi Genoni
2001-11-21 16:44 ` Swap Remco Post
2001-11-20 17:58 ` Swap Wolfgang Rohdewald
2001-11-20 21:05 ` Swap Steffen Persvold
2001-11-20 21:18 ` Swap Mike Fedyk
2001-11-20 21:33 ` Swap Nick LeRoy
2001-11-20 21:44 ` Swap Mike Fedyk
2001-11-20 22:00 ` Swap Nick LeRoy
2001-11-21 16:53 ` Swap Remco Post
2001-11-20 21:43 ` Swap Richard B. Johnson
2001-11-20 21:19 ` Swap Nick LeRoy
2001-11-21 16:48 ` Swap Remco Post
2001-11-20 20:58 ` Swap Mike Fedyk
2001-11-19 10:03 ` Swap Tim Connors
2001-11-19 10:16 ` Swap Dan Maas
[not found] <fa.kmf405v.j74f21@ifi.uio.no>
[not found] ` <fa.ns5ugpv.q02sbg@ifi.uio.no>
2001-11-20 21:26 ` Swap Dan Maas
2001-11-20 22:05 ` Swap Rik van Riel
2001-11-20 22:11 ` Swap David S. Miller
2001-11-20 22:19 ` Swap Rik van Riel
2001-11-20 22:34 ` Swap Dan Maas
2001-11-20 23:05 ` Swap Andrew Morton
[not found] ` <fa.jc73ejv.1s6e80t@ifi.uio.no>
2001-11-21 1:45 ` Swap Håvard Kvålen
2001-11-21 4:23 ` Swap Andreas Dilger
2001-11-20 22:23 ` Swap Andrew Morton
2001-11-20 23:01 ` Swap David S. Miller
2001-11-20 23:35 ` Swap Rik van Riel
2001-11-20 23:40 ` Swap David S. Miller
2001-11-21 0:19 ` Swap Rik van Riel
2001-11-21 0:21 ` Swap David S. Miller
[not found] <fa.kb6ct7v.pgku0d@ifi.uio.no>
[not found] ` <fa.k8qdvcv.184ak2l@ifi.uio.no>
2001-11-20 22:46 ` Swap Dan Maas
2001-11-20 23:17 ` Swap Trond Myklebust
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=3BF837F9.C7424E5C@cs.com \
--to=cmarslett9@cs.com \
--cc=jamagallon@able.es \
--cc=jas88@cam.ac.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=war@starband.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox