public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ed Sweetman <safemode@speakeasy.net>
To: Buddy Lumpkin <b.lumpkin@attbi.com>
Cc: Ville Herva <vherva@niksula.hut.fi>,
	Linux-kernel <linux-kernel@vger.kernel.org>
Subject: RE: About the need of a swap area
Date: 28 Jul 2002 14:58:25 -0400	[thread overview]
Message-ID: <1027882706.4228.138.camel@psuedomode> (raw)
In-Reply-To: <FJEIKLCALBJLPMEOOMECOEAPDAAA.b.lumpkin@attbi.com>

On Sun, 2002-07-28 at 14:48, Buddy Lumpkin wrote:
> 
> On Sat, Jul 27, 2002 at 03:39:41PM -0700, you [Buddy Lumpkin] wrote:
> >>
> >> Why would you want to push *anything* to swap until you have to?
> 
> >If you have idle io time in your hands, you can choose to back up some
> dirty
> >anonymous pages to the swap device. This way, when pages really needs to
> get
> >freed, you can just drop the pages (just like you would drop clean file
> >backed pages.) This obviously eliminates a great latency (somebody said
> >something about a "swap storm"), because the write happened beforehand.
> 
> >There's nothing wrong with the swap being in use (and the pages may still
> be
> >in memory). If you have swap, it makes sense to use it. What doesn't make
> >sense is to waste time waiting for paging to happen.
> 
> 
> This just flat out doesn't make sense to me ...
> 
> The system I showed stats on earlier has been up for 57 days. Periodically
> file system I/O pushes
> freemem below lotsfree and wakes up the scanner. The scanner wakes up and
> finds some filesystem
> pages that haven't been referenced or modified in a really long, long time
> and frees a few of them, then
> it goes back to sleep. This keeps a ton of pages in RAM strictly for caching
> value (although dirty pages
> are flushed periodically, they are kept in RAM too). Then when a shared
> mapping to a file occurs or a file
> is opened, and accessed with read or write, it can use the page fault
> mechanism (minor fault) to retrieve
> those pages (using vnode + offset of the page) as apposed to going to disk.
> 
> By looking at it, at one of more rare occasions, it must have pushed some
> anonymous
> pages to the swap devices, and there they sit pretty much doing nothing. But
> thats the
> nice thing about it ... Why would I want I/O going all the time in
> anticipation
> of a memory shortage that will rarely happen, or might not happen at all! If
> I understand
> you correctly, your imagining all of the up front work you could be doing in
> anticipation
> of the crawling system that could benefit from pages already pushed to the
> swap device,
> but that would only be one case.
> 
> If im willing to spend the money for tons of RAM I shouldn't have to incur
> the overhead of going
> out to the swap device at all unless I truly get short on memory.
> Don't just assume that it's inevitable that I will have to swap at some
> point.
> 
> And when you refer to idle I/O time, do you mean I/O to the swap device(s)
> or all I/O on the system (IO to all disks, network, etc..) ?
> 
> --Buddy

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.  This overhead
you're imagining doesn't occur because Overhead only exists when you're
trying to do something.  There is no drawback to how linux puts pages
into swap except what rik van riel said about battery powered boxes. 
Even so I believe that's just a /proc tunable fix.   Otherwise there is
a situation where it's advantageous to do what linux does and none where
it isn't.  

It's not like your swap device is growing and using more swap means less
space for programs.  You have X amount of swap space..  like other
people have said,  might as well make use of it if you can.  Who cares
if that situation may not occur, it's not detrimental to anything.


  reply	other threads:[~2002-07-28 18:55 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-27 12:22 About the need of a swap area 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 [this message]
2002-07-28 19:29                   ` Rik van Riel
2002-07-28 19:47                     ` Ed Sweetman
2002-07-28 20:42                       ` Buddy Lumpkin
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=1027882706.4228.138.camel@psuedomode \
    --to=safemode@speakeasy.net \
    --cc=b.lumpkin@attbi.com \
    --cc=linux-kernel@vger.kernel.org \
    --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