From: "Buddy Lumpkin" <b.lumpkin@attbi.com>
To: "Ed Sweetman" <safemode@speakeasy.net>,
"Rik van Riel" <riel@conectiva.com.br>
Cc: "Ville Herva" <vherva@niksula.hut.fi>,
"Linux-kernel" <linux-kernel@vger.kernel.org>
Subject: RE: About the need of a swap area
Date: Sun, 28 Jul 2002 13:42:10 -0700 [thread overview]
Message-ID: <FJEIKLCALBJLPMEOOMECEEBGDAAA.b.lumpkin@attbi.com> (raw)
In-Reply-To: <1027885641.4228.143.camel@psuedomode>
On Sun, 2002-07-28 at 15:29, Rik van Riel wrote:
>> On 28 Jul 2002, Ed Sweetman wrote:
>>
>> > If you bother to do any real tests you'd see that linux will swap when
>> > nothing is going on and this doesn't hinder anything.
>>
>> Linux only puts pages in swap when it's low on free physical memory.
>Perhaps, but linux considers disk cache as "in use" memory and most
>people would consider it free memory that's just temporarily being taken
>advantage of "in case". Linux will still swap even if 60% of ram is
>filesystem cache. I dont have a problem with it, was just stating some
>real observations.
I don't remember anyone implying that pages in memory that are backed by a
named file on a filesystem are "free memory" in Linux or Solaris.
If you thought you read this you should traverse the thread again.
The discussion was centered around whether it would "add value" to
preference filesystem
pages over anonymous and executable pages when you reach the point where you
have
to start looking for pages to reclaim because of a physical memory shortage.
By all means, Solaris will swap pages and eventually entire processes if it
needs to, it just tries
to grab the oldest filesystem pages first. If that's not working (memory
shortage is still getting
worse even though the scanner is running) it will reach the next watermark
which changes the behavior
of the scanner.
Another example of this kind of behavior is how the scanner in Solaris skips
over extensively shared libraries.
The scanner looks at the share reference count for each page and if the page
is shared more than
a certain amount (certain number of processes), then it is skipped during
the page scan operation.
Regards,
--Buddy
next prev parent reply other threads:[~2002-07-28 20:37 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-27 12:22 DervishD
2002-07-27 14:42 ` Ville Herva
2002-07-27 15:47 ` Rik van Riel
2002-07-27 20:41 ` Buddy Lumpkin
2002-07-27 20:50 ` Rik van Riel
2002-07-27 16:11 ` DervishD
2002-07-27 17:01 ` Ville Herva
2002-07-28 11:04 ` DervishD
2002-07-29 13:14 ` [lkml] " Ian Soboroff
2002-07-28 0:02 ` Denis Vlasenko
2002-07-27 20:58 ` Austin Gonyou
2002-07-27 22:22 ` Buddy Lumpkin
2002-07-27 23:40 ` Alan Cox
2002-07-27 22:35 ` Rik van Riel
2002-07-27 22:49 ` Buddy Lumpkin
2002-07-27 23:36 ` Daniel Phillips
2002-07-27 22:39 ` Buddy Lumpkin
2002-07-28 0:03 ` Alan Cox
2002-07-27 22:52 ` Rik van Riel
2002-07-27 23:01 ` Buddy Lumpkin
2002-07-28 0:28 ` Alan Cox
2002-07-27 23:34 ` Buddy Lumpkin
2002-07-28 6:58 ` Ville Herva
2002-07-28 7:59 ` Buddy Lumpkin
2002-07-28 8:19 ` Ville Herva
2002-07-28 14:11 ` Rik van Riel
2002-07-28 15:57 ` Ville Herva
2002-07-28 18:48 ` Buddy Lumpkin
2002-07-28 18:58 ` Ed Sweetman
2002-07-28 19:29 ` Rik van Riel
2002-07-28 19:47 ` Ed Sweetman
2002-07-28 20:42 ` Buddy Lumpkin [this message]
2002-07-28 20:27 ` Ville Herva
2002-07-30 19:31 ` Andy Isaacson
2002-07-28 16:20 ` Austin Gonyou
2002-07-29 7:18 ` Val Henson
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=FJEIKLCALBJLPMEOOMECEEBGDAAA.b.lumpkin@attbi.com \
--to=b.lumpkin@attbi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@conectiva.com.br \
--cc=safemode@speakeasy.net \
--cc=vherva@niksula.hut.fi \
/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
all inboxes | Powered by JetHome®