On Thu, 16 Mar 2000, Peter T. Breuer wrote:
> "A month of sundays ago James Sutherland wrote:"
> > On Wed, 15 Mar 2000, Sean Hunter wrote:
> > > people keep ignoring? The in-kernel OOM killer is not (meant to be) a
> > > finely-honed user-customisable tool. Its a very effective thing when
> > > the memory state is completely dire. It should never run, and when it
> > > does, its the last-ditch defence and if it wasn't there your system
> > > would die anyway.
> >
> > Precisely - complaining that you would rather have your box die
> > uncontrollably, because you are sitting there holding its hand 24x7 to
> > watch the lights go out, is hardly productive. If you ARE monitoring it
> > closely enough to fix things, you would fix them long before the disaster
> > recovery OOM routine cuts in!
>
> This is pure nonsense. You don't understand. I have _dozens_ of boxes.
>
> They work fine without OOM (i.e. in 2.0.*). With OOM they murder
> themselves.
>
> If Rik's patch gets rid of the current OOM behaviour, then I am all in
> favour of it. It cannot make things worse. But why not just get rid of
> it? Things worked fine in 2.0.*, as far as I can see. I didn't get
> cron and init being killed.
"Get rid of OOM". Wonderful! Now, if you'll just send us a copy of your
patch which gives the kernel infinite memory...
You CANNOT "get rid of" running out of memory. You have a finite amount of
memory, with various processes all taking chunks of it - once it's all
gone, you are OOM. Now, how do you "get rid of" the problem? The clone()
syscall doesn't work on DRAM...
James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:18 EST