Re: [PATCH] Prevent OOM from killing init

Please point me to an Operating System that runs on any commonly available
platform and fits your requirements.
	Nick

On Fri, 23 Mar 2001 [e-mail] wrote:

> On Fri, Mar 23, 2001 at 05:04:07PM +0000, Alan Cox wrote:
> > > This is just an escape route in case everything else has failed.
> > >
> > > Linux is unreliable.
> > > That is bad.
> >
> > Since your definition of reliability is a mathematical abstraction requiring
> > infinite storage why don't you start by inventing infinitely large SDRAM
> > chips, then get back to us ?
> 
> Ah, Alan,
> I can see that you dislike seeing me say bad things about Linux.
> I dislike having to say them.
> 
> On the other hand, my definition of reliability does not require
> infinite storage. After all, earlier Unix flavours did not need
> an OOM killer either, and my editor was not killed under Unix V6
> on 64k when I started some other process.
> 
> Linux is unreliable because a program can be killed at random,
> without warning, because of bugs in some other program.
> The old Unix guarantee that a program only crashes because of
> its own behaviour is lost. That is very sad.
> 
> What can one do? I need not tell you - you know better than I do.
> The main point is letting malloc fail when the memory cannot be
> guaranteed. There are various solutions for stack space, none of
> them very elegant, but all have in common that when we run out of
> stack space the program doing that gets SIGSEGV, and not some
> random other program. (And a well-written program could catch this
> SIGSEGV and do cleanup, preserving the integrity of its data base.
> Clearly one would want to guarantee a certain minimum stack space
> at fork time.)
> 
> Will this setup be very inefficient? I don't know. Perhaps.
> If my programs actually use 10 MB but have a guarantee for
> 200 MB then the rest of that memory is not wasted. But it can
> only be used for things that can be freed when needed, like
> inode and buffer cache.
> 
> But inefficient or not, I much prefer a system with guarantees,
> something that is reliable by default, above something that
> works well if you are lucky and fails at unpredictable moments.
> 
> Andries
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [e-mail]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>