From: Nicholas Knight <nknight@pocketinet.com>
To: vda <vda@port.imtp.ilyichevsk.odessa.ua>
Cc: linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: minimizing swap usage
Date: Tue, 25 Dec 2001 03:50:07 -0800 [thread overview]
Message-ID: <WHITE9dmLgtgGbEauz0000005b7@white.pocketinet.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0112200559350.8883-100000@shell1.aracnet.com> <WHITEp4nbukgQu0216A000005b2@white.pocketinet.com> <01122513421800.02101@manta>
In-Reply-To: <01122513421800.02101@manta>
On Tuesday 25 December 2001 07:42 am, vda wrote:
> On Tuesday 25 December 2001 09:02, Nicholas Knight wrote:
> > > > What's with all the caching when my apps crawl because it's
> > > > swapping so much ? I've tried to adjust /proc/vm/kswapd
> > > > parameters but that doesn't seem to help..I'd like to postpone
> > > > the swapping until its almost out of physical memory..
> > >
> > > This may seem counterintuitive, but postponing swapping / cache
> > > flushing to disk till the last possible moment is
> > > counterproductive. It's a little like procrastination in the time
> > > management world --
> >
> > Why not add a config option to choose between code for two
> > behaviors: (1 being the default, of course)
> > 1. Current behavior.... [snip]
> > 2. Don't swap ANYTHING to disk until avalible RAM drops below, say,
> > 15%. And put cache on a sanity check; if the system is going to
> > swap to disk because avalible RAM drops below 15%, and cache makes
> > up more than, say, 45%, start dropping the oldest stuff in the
> > cache to free up RAM instead of swapping. (I'm assuming 128-256MB+
> > of RAM here, for anything smaller, default is probably best.)
>
> There are actually two things which are usually referred to as
> 'excessive swap':
>
> (1) 'swap in'. pages which were unused for some time got swapped out
> over time, but now an app (imagine something big: Mozilla) wants them
> back and starts to read them all from swap space into RAM (+ possibly
> swapping out old pages of other apps to free that RAM first). This
> may feel sluggish but is actually correct behaviour.
*USUALY* correct.
>
> (2) 'bad cache'. Kernel swaps out and back in pages which are NOT old
> while obviously old pages are sitting in the disk cache. This is a
> kernel bug in page age calculations: kernel incorrectly thinks that
> those pages it swaps out are oldest pages in RAM, and cache pages are
> young.
>
> If you want to submit a bug report, please make sure you are seeing
> (2) and not (1).
>
This was not a bug report.
> If you want to improve swap strategy, talk to Andrea Arcangeli and/or
> Rik van Riel or search archives and read (long) 2.4.x VM battle
> threads first.
I didn't email either directly, because I doubt either has time to work
on this, since default behavior is seen as "correct", and if they do,
they will most likely notice this thread and read my message, or
someone else will point it out to them that better knows if it's a pure
waste of their time or not.
As for the VM battle threads, I read most of them as they were
happening, and I really don't give a shit about them.
next prev parent reply other threads:[~2001-12-25 11:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-20 13:30 minimizing swap usage christian e
2001-12-20 14:05 ` M. Edward (Ed) Borasky
2001-12-25 11:02 ` Nicholas Knight
[not found] ` <01122513421800.02101@manta>
2001-12-25 11:50 ` Nicholas Knight [this message]
[not found] ` <3C2B0A5A.4070101@ti.com>
[not found] ` <01122714150100.12566@manta>
2001-12-28 3:52 ` Nicholas Knight
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=WHITE9dmLgtgGbEauz0000005b7@white.pocketinet.com \
--to=nknight@pocketinet.com \
--cc=linux-kernel@vger.kernel.org \
--cc=vda@port.imtp.ilyichevsk.odessa.ua \
/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