"A month of sundays ago James Sutherland wrote:"
> 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:
> > 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...
Please read what I said instead of twisting the words! Get rid of the
current OOM _behaviour_ is what I said. The 2.0.* behaviour was fine.
2.2.* and up seem to indulge in random killing for no reason at all,
which I put down to false positives from a kill-happy something in
the kernel.
My boxes are _not_ out of memory. They all have at least 64M, and all
have swap of at least 64M too. They all run perfectly normal processes.
They have been doing this for years. Switching away from 2.0.* kernels
caused them to start dieing like flies with dead inits, dead crons, dead
whatevers. Only the lab boxes do this. Personal workstations work
fine. I presume the error situations are corrected without thinking by
someone sitting at a terminal who sees a poorly responding netscape, or
some such, or whose machine loses contact. Left on their own, the
boxes are brought down by a killer presumably in the kernel,because
that diagnosis enabled counter measures that have been 99% effective
(to wit ... maintain key daemons from init, in particular cron, who has
to check other daemons too ..).
> 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...
I don't have a problem. The current OOM behaviour does. If Rik's patch
mends it, then I am all for it.
Peter
-
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:20 EST