From: David Kulp <dkulp@neomorphic.com>
To: Kestutis Kupciunas <kesha@soften.ktu.lt>
Cc: Linux-MM@kvack.org
Subject: oom - out of memory
Date: Thu, 23 Sep 1999 11:15:01 -0700 (PDT) [thread overview]
Message-ID: <14314.28197.161697.652050@verona.neomorphic.com> (raw)
In-Reply-To: <19990920153512.A20067@alna.lt>
I have just the same problem with the same kernels: system hangs when
one process requires more than total RAM. I can't kill processes or
otherwise get any response. No syslog messages. I don't know where
to start to try to track down this problem -- but I thought monitoring
this list would be a start. Ironically -- considering the recent
'ammo' thread, I had no trouble with this in FreeBSD. )-:
If someone needs specific reproducible test cases or other details,
I'd love to try and help.
-d
ps. This isn't an X problem as could possibly be hypothesized from the
original post: this occurs when running non-X apps, too.
Kestutis Kupciunas writes:
> hello, linux memory managers,
>
> thing i am eager to clarify is oom, out of memory problem,
> which doesn't work as it is supposed to (at least i think it
> doesn't do the trick). Having the system fully utilizing all the
> memory available on box and requesting more simply "hangs"
> the box.
> Going into more details: i have noticed this behavior
> with all 2.[23].x kernels i have used (not sure about the previous series).
> usually problem arises when manipulating LARGE sets of large images
> under X (with gimp, imagemagick tools). as i open more images, naturally,
> memory/swap usage grows, and when it grows to the bounds, keyboard stops
> responding, screen stops repainting, hdd led's going crazy. all box
> services stop responding - i'm unable to connect from remote box. *RESET* :(
> this behavior isnt my box specific - i've vitnessed it happening on
> a bunch of different intels as well. The only chracteristics that apply
> to all those boxes are that all of them are x86.
> but according to the oom() function, the pid which is requesting
> memory when it's out, is beeing killed with a message.
> i didnt find any message in logs later...
> im not a 'kernel hacker', so maybe somebody could analyze the lifecycle
> of linux-mm memory allocating up to the bounds and over?
> or is there something i don't get right?
> sorry for the messy english
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
next prev parent reply other threads:[~1999-09-23 18:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-09-20 13:35 Kestutis Kupciunas
1999-09-23 18:15 ` David Kulp [this message]
1999-09-25 14:31 ` Andrea Arcangeli
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=14314.28197.161697.652050@verona.neomorphic.com \
--to=dkulp@neomorphic.com \
--cc=Linux-MM@kvack.org \
--cc=kesha@soften.ktu.lt \
/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