From: Andrea Arcangeli <andrea@suse.de>
To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Cc: riel@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: 2.4.23-pre VM regression?
Date: Thu, 16 Oct 2003 15:35:52 +0200 [thread overview]
Message-ID: <20031016133552.GD1348@velociraptor.random> (raw)
In-Reply-To: <Pine.LNX.4.44.0310161028080.2388-100000@logos.cnet>
On Thu, Oct 16, 2003 at 10:29:16AM -0200, Marcelo Tosatti wrote:
>
>
> On Thu, 16 Oct 2003, Andrea Arcangeli wrote:
>
> > On Thu, Oct 16, 2003 at 09:52:30AM -0200, Marcelo Tosatti wrote:
> > >
> > > Andrea,
> > >
> > > Martin first reported problems with "gzip -dc file | less" (280MB file).
> > > less was getting killed. He had no swap... I asked him to add some swap
> > > and it works now. Fine.
> > >
> > > The thing is that with 2.4.22 less was being killed, but with 2.4.23-pre
> > > he gets:
> >
> > note, that's a true oom, less needs to allocate 280MB and it doesn't fit
> > in ram. there's no bug as far as I can tell.
> >
> > a `vmstat 1` could confirm that.
> >
> > > >> And yes, the app was killed:
> > > > >
> > > > > __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
> > > > > VM: killing process named
> > > > > __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
> > > > > VM: killing process gpm
> > > > > __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
> > > > > VM: killing process sendmail
> > > > > __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
> > > > > VM: killing process less
> >
> > here the vm keeps killing until 'less' - the real offender - is nuked.
> >
> > > So a lot of processes which should not get killed are dying. This is
> > > really bad. I was afraid it could happen and it did.
> > >
> > > What now? Resurrect OOM-killer?
> >
> > the oom killer has the problem I outlined some email ago, with shared
> > memory it gets fooled badly etc.., though in a desktop with all tiny
> > tasks except the memory-hog (`less` in this case) it works well.
>
> Andrea,
>
> There is no memory. Right. Some task has to be killed. But not small
> programs like sendmail/named/etc. What should be killed is "less". That is
> clear, right?
sure. I think I already explained there are downsides in disabling the
oom killer for desktops where the offender task is normally the biggest
one too, but those downsides aren't something I care about given the
cases it gets right w/o it (i.e. huge-shm-SGA/mlock/oomdeadlocks). the
oom killer can do the wrong decision too sometime, and more
systematically as well.
Andrea - If you prefer relying on open source software, check these links:
rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/
http://www.cobite.com/cvsps/
next prev parent reply other threads:[~2003-10-16 13:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-16 11:52 2.4.23-pre VM regression? Marcelo Tosatti
2003-10-16 13:15 ` Tvrtko A. Uršulin
2003-10-16 13:24 ` Andrea Arcangeli
2003-10-16 12:29 ` Marcelo Tosatti
2003-10-16 13:35 ` Andrea Arcangeli [this message]
2003-10-19 23:21 ` Ken Moffat
2003-10-21 9:25 ` Stephan von Krawczynski
2003-10-27 21:11 ` Mike Fedyk
[not found] <fa.jkt135h.1l0s0t@ifi.uio.no>
[not found] ` <fa.j3l9liv.1djudhj@ifi.uio.no>
2003-10-16 23:37 ` Andreas Hartmann
-- strict thread matches above, loose matches on Subject: below --
2003-10-18 22:09 A.D.F.
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=20031016133552.GD1348@velociraptor.random \
--to=andrea@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.tosatti@cyclades.com \
--cc=riel@redhat.com \
/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.