Bug 90868 - (VM) oom_kill doesn't kill a process without SWAP
Summary: (VM) oom_kill doesn't kill a process without SWAP
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 9
Hardware: athlon
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-05-14 21:18 UTC by acount closed by user
Modified: 2007-04-18 16:53 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2003-07-22 21:09:44 UTC
Embargoed:


Attachments (Terms of Use)

Description acount closed by user 2003-05-14 21:18:15 UTC
Description of problem:

this program is killed by oom_kill if the system has SWAP, but
without SWAP it runs on a infinite loop frozen the system.

perl -e '$i=2000;while ($i--){ $a[$i]="x"x1_000_000; }'

Version-Release number of selected component (if applicable):

2.4.20-9, 256MB RAM + 256MB SWAP

How reproducible:


Steps to Reproduce:
1.
2.
3.
    
Actual results:


Expected results:


Additional info:

Comment 1 acount closed by user 2003-05-18 19:30:31 UTC
with 2.4.20-13.9 is worse, oom_kill does not kill it with SWAP memory.
System frozen.

Comment 2 acount closed by user 2003-06-08 14:25:52 UTC
kernel -18.9 has the same problem than  -13.9

Comment 3 Nathan G. Grennan 2003-06-24 14:27:49 UTC
I have a machine with 512mb of memory and no swap. In normal situtations this
works great. But I run a program that has the stupid behavior of if it doesn't
understand the file in one way it tries another way by reading the whole file
into memory. When the file is 350mb big, this ia a problem. I have set ulimits
the best I can and I have mostly gotten rid of the problem. But just last night
for no obvious reason(as in I wasn't using the problematic program) I ran into a
oom situtation. The OOM killer should have helped me in this situtation. From
what I have read of lkml archives it should do it's work in 30 seconds or less.
For me it seems to take somewhere between 30 minutes and never.

On a server with 256mb and no swap the other day I ran into a oom situation. It
had been going for at least 15 minutes before I got a sms message from the
server monitoring software. By the time I got to the console 15-20 minutes later
it had resolved itself with the oom killer.

The only recourse to patiently waiting forever is to either press the reset
button or use one of the sysrq commands. Neither is pretty.

Comment 4 Nathan G. Grennan 2003-06-24 14:44:06 UTC
Above with 2.4.20-18.9


Note You need to log in before you can comment on or make changes to this bug.