public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: 7eggert@gmx.de
Cc: Richard Purdie <rpurdie@rpsys.net>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: Linux machines dieing in swap storms
Date: Fri, 26 Oct 2007 00:03:58 -0400	[thread overview]
Message-ID: <20071026000358.56f9dec2@bree.surriel.com> (raw)
In-Reply-To: <E1IlGJV-0007vW-A6@be1.lrz>

On Fri, 26 Oct 2007 05:56:49 +0200
Bodo Eggert <7eggert@gmx.de> wrote:

> Rik van Riel <riel@redhat.com> wrote:
> > On Thu, 25 Oct 2007 16:20:41 +0100
> > Richard Purdie <rpurdie@rpsys.net> wrote:
> 
> >> Advice on solving this welcome preferably in mainline but I'll
> >> happily hack my kernels with a workaround if need be.
> > 
> > I can't see any easy hacks or workarounds to fix the issue in the
> > current MM, except maybe activate the OOM killer if the amount of
> > page cache and buffer cache is really low and swap is full...
> > 
> > In the longer run, I'm working on:
> > 
> > http://linux-mm.org/PageReplacementDesign
> 
> What about only reclaimimn cache if the cache has grown beyond a
> watermark and only reclaimimn non-cache if it's below another
> watermark? I can imagine it will solve my
> diskcache-pushes-out-mousehandler problem, and I'm pretty sure having
> very low file cache is bad for performance, too.

There are much better ways to determine such thresholds than
requiring the sysadmin to set them by hand.  I have described
one on the page linked above.

> Another thing I can imagine is to detect thrashing conditions and to
> change scheduling in order to increase the likehood of cache hits and
> thereby progress: If an application just got a page, keep it running
> for a while (accumulating negative credits).

If the process needs another page after the page it just
got (very likely), you cannot "keep it running".

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

  reply	other threads:[~2007-10-26  4:04 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <9icP2-2hb-17@gated-at.bofh.it>
     [not found] ` <9ifML-6Xs-25@gated-at.bofh.it>
2007-10-26  3:56   ` Linux machines dieing in swap storms Bodo Eggert
2007-10-26  4:03     ` Rik van Riel [this message]
2007-10-25 15:20 Richard Purdie
2007-10-25 16:13 ` Alan Cox
2007-10-25 18:28   ` Richard Purdie
2007-10-25 18:34 ` Rik van Riel
2007-10-25 19:55 ` Simon Arlott
2007-10-26  2:08 ` David Newall
2007-10-26 15:14 ` Lenar Lõhmus

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=20071026000358.56f9dec2@bree.surriel.com \
    --to=riel@redhat.com \
    --cc=7eggert@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rpurdie@rpsys.net \
    /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