[lkml]   [2001]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: "VM watchdog"? [was Re: VM nuisance]
In clouddancer.list.kernel, David wrote:

>>Didn't everyone pretty much agree that if we could turn off overcommit
>>completely and reliably, that would be the preferred solution ? Simply sig11
>>the app that's unlucky enough to want more memory than there's in the system
>>(or, horror, have malloc() fail)
>>Now, I don't remember the entire thread, but IIRC it was difficult to kill
>>overcommit completely.
>The kernel allocates memory within itself. We will still reach OOM
>conditions. It can't be avoided.

That doesn't sound good.

What bugs me about this statement was that until 2.4, I never had
lockups. I sometimes had a LOT of swapping and slow response, but I
also knew that running a complex numeric simulation when RAM <
'program needs' does that. I accepted it and tended to arrange such
runs in my absence. Now I find that I get some process nuked (or
worse - partially nuked) even after increasing to 4x swap and
eliminating lazy habits that would leave some idle process up for a
few days in case I needed it again (worked fine in 2.0.36). There are
_alot_ of good things in 2.4, but sometimes....

Does your statement imply that a machine left "alone" must eventually
OOM given enough runtime?? It seems that it must.

2.4 VM: "I'm sorry Dave ... I'm afraid I can't do that."

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:57    [W:0.048 / U:0.356 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site