It is explained here that the OOM-Killer can be configured via overcommit_memory and that:

  • 2 = no overcommit. Allocations fail if asking too much.
  • 0, 1 = overcommit (heuristically or always). Kill some process(es) based on some heuristics when too much memory is actually accessed.

Now, I may completely misunderstand that, but why isn't there an option (or why isn't it the default) to kill the very process that actually tries to access too much memory it allocated?

  • What if a critical system process asks for too much memory ? – Lawrence Jun 10 '14 at 8:40
  • In the first place - it can do this thing. But, the biggest problem with that question is that in all likelihood if a process is asking for memory then it is being newly executed - or, in other words, this is a new process involved in very current processing. Would you rather the OOM allowed your not-opened-for-3-days im client to keep on wasting system memory or would you rather YouTube actually loaded some time this year? linuxatemyram.com – mikeserv Jun 10 '14 at 8:44
  • 3
    This is what the no overcommit option essentially does. If a process asks for too much memory, it fails. If it checks for the error, it will usually kill itself; if it doesn't, it will probably get a Segmentation Error when it tries to dereference the null pointer that malloc() returns, and it will crash. – Barmar Jun 11 '14 at 19:11
  • Note that 2 is actually the no overcommit mode, according to the cited sources (such as kernel.org/doc/Documentation/vm/overcommit-accounting ). I think I'll edit your question accordingly. – hans_meine Aug 2 '18 at 10:55

Consider this scenario:

  • You have 4GB of memory free.
  • A faulty process allocates 3.999GB.
  • You open a task manager to kill the runaway process. The task manager allocates 0.002GB.

If the process that got killed was the last process to request memory, your task manager would get killed.


  • You have 4GB of memory free.
  • A faulty process allocates 3.999GB.
  • You open a task manager to kill the runaway process. The X server allocates 0.002GB to handle the task manager's window.

Now your X server gets killed. It didn't cause the problem; it was just "in the wrong place at the wrong time". It happened to be the first process to allocate more memory when there was none left, but it wasn't the process that used all the memory to start with.

| improve this answer | |
  • To extend your example it means that if a process was consuming 99.999% of your memory you'd never be able to kill it since anything that could kill it would require memory and thus get itself killed before the errant process could be killed! – Sled Jun 10 '14 at 17:22
  • 13
    Mind you, this is the Linux philosophy, not a necessary fact. Windows 3.0 solved it by having sufficient memory reserved for OOM handling, including the necessary dialogs. – MSalters Jun 10 '14 at 19:20
  • @MSalters: That doesn't really apply to the example, though; The example was about a process that has reserved nearly all memory, ie. not enough to get itself OOM killed. Obviously there has to be enough memory reserved for OOM handling on any OS. But the process that invokes the OOM handling would be the next process that happens to reserve memory, not the misbehaving one. Unless, of course, you meant that Windows 3.0 always had enough memory reserved for running task manager, or that the OOM handler always prompted the user for the process to kill. (Which != killing the offending process) – Aleksi Torhamo Jun 16 '15 at 22:58
  • 3
    @AleksiTorhamo: I indeed meant the latter. Windows 3.0 didn't have a fullblown task manager, it had the famous blue screens whose memory was preallocated. – MSalters Jun 17 '15 at 7:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.