Re: [PATCH] Prevent OOM from killing init

[Eric W. Biederman]

Guest section DW <[e-mail]> writes:

> On Fri, Mar 23, 2001 at 07:50:25AM -0700, Eric W. Biederman wrote:
> 
> > > Mar 23 11:48:49 mette kernel: Out of Memory: Killed process 2019 (emacs).
> > > Mar 23 11:48:49 mette kernel: Out of Memory: Killed process 1407 (emacs).
> > > Mar 23 11:48:50 mette kernel: Out of Memory: Killed process 1495 (emacs).
> > > Mar 23 11:48:50 mette kernel: Out of Memory: Killed process 2800 (rpm).
> > > 
> > > [yes, that was rpm growing too large, taking a few emacs sessions]
> > > [2.4.2]
> > 
> > Let me get this straight you don't have enough swap for your workload?
> > And you don't have per process limits on root by default?
> > 
> > So you are complaining about the OOM killer?  
> 
> I should not react - your questions are phrased rhetorically.

To some extent I was also very puzzled by your complaint.

You have setup a system that by your definition unreliably and then
you complain it is unreliable.

> 
> But yes, I am complaining because Linux by default is unreliable.
> I strongly prefer a system that is reliable by default,
> and I'll leave it to others to run it in an unreliable mode.

Now all I know the system didn't have enough resources to do what
you asked to it do and it failed.  That sounds reliable to me.  

Obviously you were suprised at how the system failed.  Given
that unix has been doing this kind of thing for decades, you obviously
missed how the unix malloc overcommited memory.

Does you application trap sigsegv on a different stack so you can
catch stack growth failure?  And how does your app handle this case?

Having a no over commit kernel option would help.  

A cheap workaround is to call mlock_all(MCL_FUTRE...).  Then you are
garantteed you will always have ram locked into memory for your
program.   This assumes you have enough ram for your program.

Eric