From: Robert Love <rml@tech9.net>
To: "José Luis Domingo López" <jldomingo@crosswinds.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: OOM: A Success Report
Date: 07 Jul 2001 19:01:31 -0400 [thread overview]
Message-ID: <994546903.1747.1.camel@phantasy> (raw)
In-Reply-To: <20010708004051.A4765@dardhal.mired.net>
In-Reply-To: <20010708004051.A4765@dardhal.mired.net>
On 08 Jul 2001 00:40:51 +0000, José Luis Domingo López wrote:
> <snip>
> Another interesting thing I noted is the fact (as shown by Robert Love's
> message) that oom_kill() seems to kill processes without taking into
> account whether the selected process is a full application or just one
> of more "threads" in some application. This happened to me when OpenOffice
> went crazy and OOM hit, but instead of killing the parent process, it just
> killed one of the children and, though OOM recoverd memory, OpenOffice
> ended useless. Maybe OOM should have killed the parent in the first place.
for whatever reason, i did not even notice this. i guess because
evolution itself exited, for some reason (normally if a single component
dies, say mail, it just puts a dialog up saying `mail component died').
i think there may be problems with determining what the parent app is,
or if there is a parent app. killing the PPID may not always be the
answer (but in many cases, like what you gave, is a very good answer).
> Final question: a 2.4.4 kernel with no swap activated, and OOM hit (thanks
> to a purposedly executed ls ../*/../*/..) takes much more time to recover
> than the same setup but with swap activated (exact numbers missing,
> sorry). Moreover, when swap is of, the hard disk goes crazy as if it where
> using swap, when in fact it isn't). Is this expected behaviour ?
i think i recall hearing about this, and the reply was something to the
effect of `its known but not wanted'.
> If someone wants some test with real numbers, please let me know and
> though I'm on vacation, I'll go where I work to make some test :)
i forgot to give any stats from my incident. i couldnt access the
console (the machine was almost locked, the mouse barely moved), so i
dont have any hard numbers.
from my gnome applets <g> i see load was approaching 10, memory was (or
was close to) 100%, and swap was growing close to 100%.
this is kernel 2.4.6-ac2, x86, with 256MB memory, 768MB swap.
after the incident memory was done to the bare load with only 30MB of
cache and swap was only at about 20MB use.
i restarted X but not the system, and all is well.
--
Robert M. Love
rml at ufl.edu
rml at tech9.net
next prev parent reply other threads:[~2001-07-07 23:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-07 22:00 OOM: A Success Report Robert Love
2001-07-08 0:40 ` José Luis Domingo López
2001-07-07 23:01 ` Robert Love [this message]
2001-07-08 1:20 ` Daniel Phillips
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=994546903.1747.1.camel@phantasy \
--to=rml@tech9.net \
--cc=jldomingo@crosswinds.net \
--cc=linux-kernel@vger.kernel.org \
/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.