[lkml]   [2000]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectOOM Test Case - Failed!
I am very unimpressed with the current OOM killer. After 10 days of online
time, I decided to try compiling gcc again, the very culprit that killed my
last system using 2.4.0-test8 Friday night (to which I was unable to reset
the system until Monday morning).

GCC started compiling normally, until it reached the command:
./genattrtab ../../gcc/config/i386/ > tmp-attrtab.c

At this time, genattrtab started to accumulate 70+ Megabytes of memory. For
comparison, I only have 32MB of RAM and 64MB of swap space. Also during this
time were several daemon and user-level programs running, using at most 4MB
of ram each and running peacefully in the background.

The system slowed down to a crawl. 5 minutes later, the OOM killer finally
kicked in and killed 5 processes: <httpd>. I figure, okay, httpd doesn't need
to run, I'd rather give the GCC-compilation the extra RAM it needs to finish
its 'genattrtab' program.

10 minutes pass and the system does not get better. Then all of a sudden, the
console flashes with more <httpd> processes killed. "What is going on here," I
thought to myself. There were only 6 httpd processes running when I first
started the compilation. It appears that the OOM killer destroyed only the
children of the Apache web daemon, and not the daemon itself! The web daemon
just spawned more httpd processes to fill in the children that it lost earlier.

Meanwhile, genattrtab continued to consume RAM in the background. After 10 more
minutes of waiting on the OOM killer, I come back to a console that is filled
with 'Killing process <httpd>' messages. It never had the bright idea to kill
the parent or any process OTHER than httpd.

The expected process to kill here would be ./genattrtab, which at the time was
consuming more RAM than available and had only started 25 minutes prior...

root 1099 63.6 61.5 71424 18740 pts/0 R 09:39 1:22 ./genattrtab

This was my first OOM killer test, run on 2.4.0-test9-final with Rik's VM
patches that went into test10-pre1. My prognosis is that the VM runs almost 2x
as fast when there is memory available and swapping occurs, compared to the
old VM. However, when memory runs out, it takes up to 5 minutes for the OOM
killer to start killing processes, and does a bad job at that.

Granted, the random OOM killer in 2.2 was better at its job than this because
it brought back a usable system. Even something that killed the process that's
using the most RAM or the process that allocates the most space in a set period
of time would be good in this case. We need to decide on a better algorithm,
albeit simple, that will alleviate this problem before 2.4.0 final comes out.


Byron Stanoszek Ph: (330) 644-3059
Systems Programmer Fax: (330) 644-8110
Commercial Timesharing Inc. Email:

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:41    [W:0.062 / U:6.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site