All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Heler <lkml@lpbproductions.com>
To: linux-kernel@vger.kernel.org
Subject: Re: excessive swapping
Date: Fri, 13 Aug 2004 02:00:02 -0700	[thread overview]
Message-ID: <200408130200.02828.lkml@lpbproductions.com> (raw)
In-Reply-To: <1092381036.2597.29.camel@rivendell.home.local>

Can you try using Nick Piggin's np patchset ? 

Matt H.

On Friday 13 August 2004 12:10 am, Florin Andrei wrote:
> On Thu, 2004-08-12 at 23:44, Florin Andrei wrote:
> > On Thu, 2004-08-12 at 23:40, Florin Andrei wrote:
> > > The system is swapping excessively. There's no way the total size of
> > > the applications exceeds the size of RAM. There's plenty of room to
> > > spare, yet 16% of the 530MB of swap is used.
> >
> > Now it's 22% and counting. Way to go. :-(
>
> Now it's 27%. You get the picture.
>
> Anyway, out of the 512MB of RAM, like 390MB are disk cache. No wonder
> that the useful pages are swaped out.
>
> It seems like the kernel believes that the disk cache has some
> miraculous properties w.r.t. the system performance, and desperately
> tries to grow it as much as possible.
> This is wrong religion. The reality is opposite. The system is much
> slower, because applications are thrown out in the swap, then sucked
> back in, which is a very slow process.
>
> The efficiency of increasing the disk cache decreases exponentially with
> size, like any other cache. Then what's the point of sacrificing useful
> memory just to increase some hypothetical "useful" cache?
>
> Even on a server, the same universal laws still apply, the efficiency of
> increasing cache still decreases exponentially. There's still precious
> time wasted when an application is sucked back in from swap, at the
> price of an immeasurably small performance gain due to the disk cache
> being larger.
>
> I'm sorry for rambling, but to me the current swapping policy is so
> blatantly wrong. Besides the space occupied by the apps themselves,
> there's a lot of room to _spare_ - then why swap?

  parent reply	other threads:[~2004-08-13  8:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-13  6:40 excessive swapping Florin Andrei
2004-08-13  6:44 ` Florin Andrei
2004-08-13  7:10   ` Florin Andrei
2004-08-13  7:24     ` dvd ripping causing: " bert hubert
2004-08-13  9:00     ` Matt Heler [this message]
2004-08-13 12:10     ` Alan Cox
2004-08-13  7:10 ` bert hubert
2004-09-02  6:02 ` Florin Andrei
2004-09-28 15:39   ` Marcelo Tosatti

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=200408130200.02828.lkml@lpbproductions.com \
    --to=lkml@lpbproductions.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkml@lpbproduction.scom \
    /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.