Messages in this thread | | | Date | Thu, 16 Mar 2000 10:46:13 +0000 (GMT) | From | James Sutherland <> | Subject | Re: Some questions about linux kernel. |
| |
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/
| |