public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Ford <david@blue-labs.org>
To: "Jakob Østergaard" <jakob@unthought.net>
Cc: Pavel Machek <pavel@suse.cz>, linux-kernel@vger.kernel.org
Subject: Re: "VM watchdog"? [was Re: VM nuisance]
Date: Thu, 16 Aug 2001 21:26:38 -0400	[thread overview]
Message-ID: <3B7C72CE.60601@blue-labs.org> (raw)
In-Reply-To: <3B748AA8.4010105@blue-labs.org> <20010814140011.B38@toy.ucw.cz> <20010817002420.C30521@unthought.net>

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.

David

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.

David



  reply	other threads:[~2001-08-17  1:27 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-11  1:30 VM nuisance David Ford
2001-08-11  2:48 ` Rik van Riel
2001-08-11  2:59   ` H. Peter Anvin
2001-08-11  4:17     ` Rik van Riel
2001-08-11  4:40       ` David Ford
2001-08-11  4:46         ` Rik van Riel
2001-08-11  4:41       ` safemode
2001-08-11  5:00       ` H. Peter Anvin
2001-08-11 13:13     ` Alan Cox
2001-08-11 15:39       ` David Ford
2001-08-11  3:50   ` safemode
2001-08-12 13:09   ` Maciej Zenczykowski
2001-08-12 13:45     ` Rik van Riel
2001-08-16 23:29       ` Justin A
2001-08-17  0:06         ` Dr. Kelsey Hudson
2001-08-17  0:24           ` Justin A
2001-08-17  2:54             ` Dr. Kelsey Hudson
2001-08-12 23:05     ` Dan Mann
     [not found]   ` <9l5v9a$ha9$1@ns1.clouddancer.com>
2001-08-13  0:01     ` Colonel
2001-08-13 14:32   ` dean gaudet
2001-08-13 19:47     ` Brian
2001-08-14  8:27     ` Helge Hafting
2001-08-17 13:34       ` Szabolcs Szakacsits
2001-08-17 17:29         ` Rik van Riel
2001-08-14 14:00 ` "VM watchdog"? [was Re: VM nuisance] Pavel Machek
2001-08-16 22:24   ` Jakob Østergaard
2001-08-17  1:26     ` David Ford [this message]
2001-08-17  1:41       ` Jakob Østergaard
     [not found]       ` <9li6sf$h5$1@ns1.clouddancer.com>
2001-08-17  9:04         ` Colonel
2001-08-17 20:38           ` David Ford

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3B7C72CE.60601@blue-labs.org \
    --to=david@blue-labs.org \
    --cc=jakob@unthought.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox