Ever seen OOM killer pick a process while it is core dumping to tmpfs?
From: Kasper Dupont (kasperd_at_daimi.au.dk)
Date: 09/15/05
- Next message: Diego Billi: "How VMWare shares network interface?"
- Previous message: shiva: "need some advice to makea multiuser network game...."
- Next in thread: Måns Rullgård: "Re: Ever seen OOM killer pick a process while it is core dumping to tmpfs?"
- Reply: Måns Rullgård: "Re: Ever seen OOM killer pick a process while it is core dumping to tmpfs?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 15 Sep 2005 12:09:10 +0200
I tell you, it ain't a pretty sight.
I was testing some code on some large amounts of data.
Eventually it would overflow a buffer (I know, I'd better
fix that bug ASAP). So it started dumping core to the
current directory, which happened to be the tmpfs mounted
on /tmp. Soon it ran out of swap. (I have 1280MB of RAM
and 2GB of swap, the process used about 2GB of virtual
memory when it crashed). The OOM killer quickly realized
which process was responsible for the system running out
of virtual memory and wanted to kill it. However it just
kept allocating more swap as /tmp/core needed to grow.
Are there some good changes one could make to the kernel
to prevent such a case from getting out of hand? Maybe
have tmpfs report ENOSPC in such a case. But should it
report ENOSPC to all processes, or just the one picked
by the OOM killer?
-- Kasper Dupont Note to self: Don't try to allocate 256000 pages with GFP_KERNEL on x86.
- Next message: Diego Billi: "How VMWare shares network interface?"
- Previous message: shiva: "need some advice to makea multiuser network game...."
- Next in thread: Måns Rullgård: "Re: Ever seen OOM killer pick a process while it is core dumping to tmpfs?"
- Reply: Måns Rullgård: "Re: Ever seen OOM killer pick a process while it is core dumping to tmpfs?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
