When Linux Runs Out of Memory
Subject:   OOM Behaviour
Date:   2006-12-04 06:41:45
From:   Teresa3455

First of all, thanks for the article. I found it very useful.

I compiled loop-callo.c on my desktop machine. I ran it, and suddenly my firefox session was killed by OOM.

I don't understand why firefox was killed instead of the newly-created memory-eating process. Firefox was started much before loop-call was.

Is there anyother way to adjust OOM behaviour other than placing "OOM_DISABLE" on /proc/<pid>/oomadj ?


P.S : Good link ->

Full Threads Oldest First

Showing messages 1 through 1 of 1.

  • OOM Behaviour
    2006-12-05 22:53:09  mulyadi_santosa [View]

    Hi Teresa

    It's good to hear that you found this article to be useful. Please don't be hesitate to write further comments about it.

    About FF (Firefox) got killed instead of loop-calloc, I have a pretty good guess that FF had bigger VM size than loop-calloc when OOM killer was working in your case. Recall that running time is just one of the killer's criteria, so to predict which application get killed, you need to carefully check all those 7 criterias I have mentioned in the article.

    I have tried to mimic your case, simply by doing tail -f /dev/zero while FF 1.0.4 was running. Instead of killing tail right away, FF was killed together with other application such as KDE panel and KMail. Top reported that FF consumed ~33MB of virtual memory while free+reclaimable RAM was about ~30 MB before loop-calloc was started.

    My suggestion, instead of looking ways to disable OOM killer, is to use ulimit whenever you want to start a memory hogger application. Start a shell (possibly via xterm or Konsole), ulimit -v <some amount of memory> and start the application after that. Assuming the application does proper checking after malloc() and strict overcommit is enabled, there is no need for OOM-killer to randomly kills application..which is in your case, ended up with killing innocent FF.