All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Rik van Riel <riel@conectiva.com.br>
Cc: Andrew Morton <akpm@zip.com.au>,
	Marcelo Tosatti <marcelo@conectiva.com.br>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: 2.4.16 & OOM killer screw up (fwd)
Date: Wed, 12 Dec 2001 11:09:42 +0100	[thread overview]
Message-ID: <20011212110942.X4801@athlon.random> (raw)
In-Reply-To: <20011212102141.Q4801@athlon.random> <Pine.LNX.4.33L.0112120739380.20576-100000@imladris.surriel.com>
In-Reply-To: <Pine.LNX.4.33L.0112120739380.20576-100000@imladris.surriel.com>; from riel@conectiva.com.br on Wed, Dec 12, 2001 at 07:45:45AM -0200

On Wed, Dec 12, 2001 at 07:45:45AM -0200, Rik van Riel wrote:
> On Wed, 12 Dec 2001, Andrea Arcangeli wrote:
> > On Wed, Dec 12, 2001 at 12:44:17AM -0800, Andrew Morton wrote:
> > > Oh.  Maybe the core design (whatever it is :)) is not finished,
> > > because it retains the bone-headed, dumb-to-the-point-of-astonishing
> > > misfeature which Linux VM has always had:
> > >
> > > If someone is linearly writing (or reading) a gigabyte file on a 64
> > > megabyte box they *don't* want the VM to evict every last little scrap
> > > of cache on behalf of data which they *obviously* do not want
> > > cached.
> >
> > The current design tries to detect this, at least much much better than
> > 2.2. This is why I disagree with Rik's patch of yesterday.  detecting
> > cache pollution is good also on the lowmem boxes (not only for DB).
> 
> Oh, absolutely. The problem just is that the current design
> has even worse problems where it doesn't put any pressure on
> pages which were touched twice an hour ago.

it does. See the refill_inactive pass.

> This leads to the situation that applications get OOM-killed
> to preserve buffer cache memory which hasn't been touched
> since bootup time.

It doesn't happen here.

At the very least the fix is the two liner from Andrew that forces a
nr_pages refile from active list, that will guarantee that whatever
happens we always roll the active list too, but the oom killing you are
experiencing is a problem of mainline, it definitely doesn't happen here
and the refill_inactive(0) cannot be the culprit because the active list
grows always to a relevant size and if during oom a few pages stays
untouched into the active list that's fine, those two pages couldn't
save us anyways so they'd better stay there so we don't trash.

> 
> There are ways to both have good behaviour on bulk IO and
> flush out old data which was in active use but no longer is.
> I believe these are called page aging and drop-behind.
> I've been thinking about achieving the wanted behaviour
> without these two, but haven't been able to come up with
> any algorithm which doesn't have some very bad side effects.
> 
> If you know a way of doing bulk IO properly and flushing out
> an old working set correctly, please let us know.
> 
> regards,
> 
> Rik
> -- 
> Shortwave goes a long way:  irc.starchat.net  #swl
> 
> http://www.surriel.com/		http://distro.conectiva.com/


Andrea

  reply	other threads:[~2001-12-12 10:09 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-10 19:08 2.4.16 & OOM killer screw up (fwd) Marcelo Tosatti
2001-12-10 20:47 ` Andrew Morton
2001-12-10 19:42   ` Marcelo Tosatti
2001-12-11  0:11   ` Andrea Arcangeli
2001-12-11  7:07     ` Andrew Morton
2001-12-11 13:32       ` Rik van Riel
2001-12-11 13:46         ` Andrea Arcangeli
2001-12-12  8:44           ` Andrew Morton
2001-12-12  9:21             ` Andrea Arcangeli
2001-12-12  9:45               ` Rik van Riel
2001-12-12 10:09                 ` Andrea Arcangeli [this message]
2001-12-12  9:59               ` Andrew Morton
2001-12-12 10:15                 ` Andrea Arcangeli
2001-12-11 13:42       ` Andrea Arcangeli
2001-12-11 13:59         ` Rik van Riel
2001-12-11 14:23           ` Andrea Arcangeli
2001-12-11 15:27             ` Daniel Phillips
2001-12-12 11:16               ` Andrea Arcangeli
2001-12-12 20:03                 ` Daniel Phillips
2001-12-12 21:25                   ` Andrea Arcangeli
2001-12-11 13:59         ` Abraham vd Merwe
2001-12-11 14:01           ` Andrea Arcangeli
2001-12-11 17:30             ` Leigh Orf
2001-12-11 15:47         ` Henning P. Schmiedehausen
2001-12-11 16:01           ` Alan Cox
2001-12-11 16:37           ` Hubert Mantel
2001-12-11 17:09           ` Rik van Riel
2001-12-11 17:28             ` Alan Cox
2001-12-11 17:22               ` Rik van Riel
2001-12-11 17:23               ` Christoph Hellwig
2001-12-12 22:20                 ` Rob Landley
2001-12-13  8:48                   ` Alan Cox
2001-12-13  8:47                     ` David S. Miller
2001-12-13 18:41                       ` Matthias Andree
2001-12-13 10:22                     ` [OT] " Rob Landley
2001-12-12  8:39         ` Andrew Morton
2001-12-11  0:43 ` Andrea Arcangeli
2001-12-11 15:46   ` Luigi Genoni
2001-12-12 22:05   ` Ken Brownfield
2001-12-12 22:30     ` Andrea Arcangeli
2001-12-12 23:23     ` Rik van Riel
     [not found] <Pine.LNX.4.33L.0112102004490.1352-100000@duckman.distro.conectiva>
2001-12-11 16:45 ` Marcelo Tosatti
2001-12-11 18:51   ` Rik van Riel

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=20011212110942.X4801@athlon.random \
    --to=andrea@suse.de \
    --cc=akpm@zip.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    --cc=riel@conectiva.com.br \
    /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.