Taming the OOM killer
Posted Feb 5, 2009 9:07 UTC (Thu) by brouhaha
In reply to: Taming the OOM killer
Parent article: Taming the OOM killer
if you could allocate the address space but then tell the kernel "don't
really use it"
I'm not telling the kernel "don't use it". If the kernel needs to, it will use it. For the primary case people seem concerned with, the time between fork() and exec(), it will be committed but due to COW, it won't actually get used. It may still get used for other cases, and within reason that's a good thing, but a user-space daemon can take some system-specific corrective action if it gets out of hand. This provides a whole lot more flexibility in error handling than a user-space daemon that would only control the behavior of the OOM killer.
you may be ok, but how is that different from the current
It's different because the kernel is NEVER going to kill an unrelated process selected by a heuristic. It is going to fail an allocation or fork, and the software can take some reasonable recovery action.
The system should not be designed or configured such that the kernel can fail to provide memory that has been committed, because there is NO reasonable recovery mechanism for that. It is far easier to handle memory allocation problems gracefully when the error is reported at the time of the attempt to commit the memory, rather than at some random future time.
to post comments)