[lkml]   [2001]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: "VM watchdog"? [was Re: VM nuisance]
I think it is an excellent way to do it.  Nobody said you have to run 
the program and nobody forces you to use a particular program with a
particular policy. It puts the OOM policy in userland where -you-
decide when and how things happen.


Jakob Østergaard wrote:

>>Maybe creating userland program that
>>*) allocates few megs
>>*) while 1 sleep 1m, gettimeofday. If more tha two minutes elapsed,
>> tell OOM handler to kick in.
>On my compute-server in the basement this is completely unacceptable because it
>*may* just be working hard on something big. The excessive swapping may just
>be 10-30 minutes where some app is using way more memory than the box has RAM,
>in this case it's no problem at all, and all your suggestion would give me is
>randomly dying compute jobs.
>On my desktop this is unacceptable as well. You want the system to be frozen
>for more than two minutes before doing anything about it ?
>The problem with using such vague heuristics against fixed (arbitrary) limits
>is that the effect will almost always be completely unacceptable. Either your
>arbitrary limit is way too high, or way too low.
>I can't tell you how to do it - but I think your suggestion is an excellent way
>to *not* do it :)
>>Or maybe kernel could have some "VM watchdog", which would trigger OOM if
>>it is not polled once a minute...
>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.


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.071 / U:0.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site