From: Andy Isaacson <adi@hexapodia.org>
To: Andrew Morton <akpm@osdl.org>
Cc: elf@buici.com, riel@redhat.com, brettspamacct@fastclick.com,
jgarzik@pobox.com, linux-kernel@vger.kernel.org
Subject: Re: ~500 megs cached yet 2.6.5 goes into swap hell
Date: Thu, 29 Apr 2004 17:27:04 -0500 [thread overview]
Message-ID: <20040429222704.GD5957@hexapodia.org> (raw)
In-Reply-To: <20040429134222.291f83d4.akpm@osdl.org>
On Thu, Apr 29, 2004 at 01:42:22PM -0700, Andrew Morton wrote:
> Andy Isaacson <adi@hexapodia.org> wrote:
> > What I want is for purely sequential workloads which far exceed cache
> > size (dd, updatedb, tar czf /backup/home.nightly.tar.gz /home) to avoid
> > thrashing my entire desktop out of memory. I DON'T CARE if the tar
> > completed in 45 minutes rather than 80. (It wouldn't, anyways, because
> > it only needs about 5 MB of cache to get every bit of the speedup it was
> > going to get.) But the additional latency when I un-xlock in the
> > morning is annoying, and there is no benefit.
>
> What kernel version are you using? If 2.6, what value of
> /proc/sys/vm/swappiness?
2.4.various, including 2.4.25 and 2.4.26. I haven't taken the 2.6
plunge yet. Running on various x86 including
- dual PIII 666 MHz 512 MB
- SpeedStep PIII 700 MHz 128 MB
- Athlon XP 2GHz 512 MB
> > For a more useful example, ideally I *should not be able to tell* that
> > "dd if=/hde1 of=/hdf1" is running.
>
> I just did a 4GB `dd if=/dev/sda of=/x bs=1M' on a 1GB 2.6.6-rc2-mm2
> swappiness=85 machine here and there was no swapout at all.
>
> Probably your machine has less memory. But without real, hard details
> nothing can be done.
I'm pleased to hear that 2.6 is apparently better behaved. In your
test, what was the impact on the file cache? It's a big improvement to
not be paging out to swap, but it's also important that sequential IO
not evict my cached build tree.
An interesting test would be to time a compilation of a source file with
a large number of includes. For example, building
linux-2.4.25/kernel/sysctl.c on my Athlon XP 2GHz, 512MB, 2.4.25 takes
2.8 seconds with (fairly) cold cache. (I didn't reboot, but I did take
fairly extreme measures to force stuff out.) It takes 0.54 seconds with
warm caches. After doing 1GB of sequential IO (wc -w /tmp/bigfile) I'm
back up to 2.08 seconds.
> > There is *no* benefit to cacheing
> > more than about 2 pages, under this workload.
>
> Sure, we could do better things with the large streaming files, although
> the risk of accidentally screwing up particular workloads is high.
Yeah, I agree. For example, I've occasionally used cat(1) or wc(1) to
prefetch files that I knew I was going to be accessing randomly; with my
hypothetical "sequential IO doesn't cause cacheing" it would be much
harder to do effective manual prefetching.
> But the use-once logic which we have in there at present does handle these
> cases quite well.
Where is the use-once logic available? Is it in mainstream 2.6 or only
in some development branches? I've not upgraded from 2.4 mostly because
I didn't see much benefits evident in the discussions, but improved
paging logic would be nice.
> > But with current kernels,
> > IME, that workload results in a gargantuan buffer cache and lots of
> > swapout of apps I was using 3 minutes ago. I've taken to walking away
> > for some coffee, coming back when it's done, and "sudo swapoff
> > /dev/hda3; sudo swapon -a" to avoid the latency that is so annoying when
> > trying to use bloaty apps.
>
> What kernel, what system specs, what swappiness setting?
2.4.25, Athlon XP 2 GHz, 512MB. I suppose you're not terribly
interested in 2.4. I'll see if I can reasonably upgrade, if you can
tell me what I should upgrade to for the good stuff.
-andy
next prev parent reply other threads:[~2004-04-29 22:27 UTC|newest]
Thread overview: 128+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-28 21:27 ~500 megs cached yet 2.6.5 goes into swap hell Brett E.
2004-04-29 0:01 ` Andrew Morton
2004-04-29 0:10 ` Jeff Garzik
2004-04-29 0:21 ` Nick Piggin
2004-04-29 0:50 ` Wakko Warner
2004-04-29 0:53 ` Jeff Garzik
2004-04-29 0:54 ` Nick Piggin
2004-04-29 1:51 ` Tim Connors
2004-04-29 21:45 ` Denis Vlasenko
2004-04-29 0:58 ` Marc Singer
2004-04-29 3:48 ` Nick Piggin
2004-04-29 4:20 ` Marc Singer
2004-04-29 4:26 ` Nick Piggin
2004-04-29 14:49 ` Marc Singer
2004-04-30 4:08 ` Nick Piggin
2004-04-30 22:31 ` Marc Singer
2004-04-29 6:38 ` William Lee Irwin III
2004-04-29 7:36 ` Russell King
2004-04-29 10:44 ` Nick Piggin
2004-04-29 11:04 ` Russell King
2004-04-29 14:52 ` Marc Singer
2004-04-29 20:01 ` Horst von Brand
2004-04-29 20:18 ` Martin J. Bligh
2004-04-29 20:33 ` David B. Stevens
2004-04-29 22:42 ` Steve Youngs
2004-04-29 20:36 ` Paul Jackson
2004-04-29 21:19 ` Andrew Morton
2004-04-29 21:34 ` Paul Jackson
2004-04-29 21:57 ` Andrew Morton
2004-04-29 22:18 ` Paul Jackson
2004-04-30 0:04 ` Andy Isaacson
2004-04-30 0:32 ` Andrew Morton
2004-04-30 0:54 ` Paul Jackson
2004-04-30 5:38 ` Andy Isaacson
2004-04-30 6:00 ` Nick Piggin
2004-04-30 7:52 ` Jeff Garzik
2004-04-30 8:02 ` Andrew Morton
2004-04-30 8:09 ` Jeff Garzik
2004-05-06 13:08 ` Pavel Machek
2004-05-07 15:53 ` Hugh Dickins
2004-05-07 16:57 ` Pavel Machek
2004-05-07 17:30 ` Timothy Miller
2004-05-07 17:43 ` Hugh Dickins
2004-05-07 17:48 ` Mark Frazer
2004-05-12 17:52 ` Rob Landley
2004-05-17 20:16 ` Hugh Dickins
2004-04-29 21:38 ` Timothy Miller
2004-04-29 21:47 ` Paul Jackson
2004-04-29 22:18 ` Timothy Miller
2004-04-29 22:46 ` Paul Jackson
2004-04-29 23:08 ` Timothy Miller
2004-04-30 12:31 ` Bart Samwel
2004-04-30 15:35 ` Clay Haapala
2004-04-30 15:44 ` Bart Samwel
2004-04-30 22:11 ` Paul Jackson
2004-04-30 3:37 ` Tim Connors
2004-04-30 5:15 ` Nick Piggin
2004-04-30 6:20 ` Tim Connors
2004-04-30 6:34 ` Nick Piggin
2004-04-30 7:05 ` Tim Connors
2004-04-30 7:15 ` Nick Piggin
2004-04-30 9:18 ` Re[2]: " vda
2004-04-30 9:33 ` Arjan van de Ven
2004-04-30 11:33 ` Denis Vlasenko
2004-04-30 16:19 ` Timothy Miller
2004-04-29 0:49 ` Brett E.
2004-04-29 1:00 ` Andrew Morton
2004-04-29 1:24 ` Jeff Garzik
2004-04-29 1:40 ` Andrew Morton
2004-04-29 1:47 ` Rik van Riel
2004-04-29 18:14 ` Adam Kropelin
2004-04-30 3:17 ` Tim Connors
2004-04-29 2:19 ` Tim Connors
2004-04-29 16:24 ` Martin J. Bligh
2004-04-29 16:36 ` Chris Friesen
2004-04-29 16:56 ` Martin J. Bligh
2004-04-29 1:30 ` Paul Mackerras
2004-04-29 1:31 ` Paul Mackerras
2004-04-29 1:53 ` Andrew Morton
2004-04-29 2:40 ` Andrew Morton
2004-04-29 2:58 ` Paul Mackerras
2004-04-29 3:09 ` Andrew Morton
2004-04-29 3:14 ` William Lee Irwin III
2004-04-29 6:12 ` Benjamin Herrenschmidt
2004-04-29 6:22 ` Andrew Morton
2004-04-29 6:25 ` Benjamin Herrenschmidt
2004-04-29 6:31 ` William Lee Irwin III
2004-04-29 16:50 ` Martin J. Bligh
2004-04-29 3:57 ` Nick Piggin
2004-04-29 14:29 ` Rik van Riel
2004-04-30 3:00 ` Nick Piggin
2004-04-30 12:50 ` Rik van Riel
2004-04-30 13:07 ` Nick Piggin
2004-04-30 13:18 ` Nikita Danilov
2004-04-30 13:39 ` Nick Piggin
2004-04-29 1:46 ` Rik van Riel
2004-04-29 1:57 ` Andrew Morton
2004-04-29 2:29 ` Marc Singer
2004-04-29 2:35 ` Andrew Morton
2004-04-29 3:10 ` Marc Singer
2004-04-29 3:19 ` Andrew Morton
2004-04-29 4:13 ` Marc Singer
2004-04-29 4:33 ` Andrew Morton
2004-04-29 14:45 ` Marc Singer
2004-04-29 16:51 ` Andy Isaacson
2004-04-29 20:42 ` Andrew Morton
2004-04-29 22:27 ` Andy Isaacson [this message]
2004-04-29 23:19 ` Andrew Morton
2004-04-30 0:14 ` Lincoln Dale
2004-04-29 8:02 ` Wichert Akkerman
2004-04-29 14:25 ` Marcelo Tosatti
2004-04-29 14:27 ` Wichert Akkerman
2004-04-29 2:41 ` Rik van Riel
2004-04-29 2:43 ` Andrew Morton
2004-04-29 1:41 ` Tim Connors
2004-04-29 9:43 ` Helge Hafting
2004-04-29 14:48 ` Marc Singer
2004-04-29 0:44 ` Brett E.
2004-04-29 1:13 ` Andrew Morton
2004-04-29 1:29 ` Brett E.
2004-04-29 18:05 ` Brett E.
2004-04-29 18:32 ` William Lee Irwin III
2004-04-29 20:47 ` Brett E.
2004-04-29 0:04 ` Brett E.
2004-04-29 0:13 ` Jeff Garzik
2004-04-29 0:43 ` Nick Piggin
2004-04-29 13:51 ` Horst von Brand
2004-04-29 18:32 ` Brett E.
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=20040429222704.GD5957@hexapodia.org \
--to=adi@hexapodia.org \
--cc=akpm@osdl.org \
--cc=brettspamacct@fastclick.com \
--cc=elf@buici.com \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.