Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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

  • 1 = no overcommit. Allocations fail if asking too much.
  • 0, 2 = overcommit. 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?

share|improve this question
    
What if a critical system process asks for too much memory ? –  Lawrence Jun 10 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 at 8:44
    
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 at 19:11

1 Answer 1

up vote 17 down vote accepted

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.

Or:

  • 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.

share|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! –  ArtB Jun 10 at 17:22
3  
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 at 19:20

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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