From: Dan Kegel <dank@kegel.com>
To: Jesse Pollard <pollard@admin.navo.hpc.mil>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Protecting processes from the OOM killer
Date: Mon, 03 Mar 2003 08:41:20 -0800 [thread overview]
Message-ID: <3E6385B0.1010706@kegel.com> (raw)
In-Reply-To: <200303030845.00097.pollard@admin.navo.hpc.mil>
Jesse Pollard wrote:
> On Friday 28 February 2003 10:08 am, Dan Kegel wrote:
>
>>Alan Cox wrote:
>
> snip
>
>>>Everything else is armwaving "works half the time" stuff. By the time
>>>the OOM kicks in the game is already over.
>>
>>Even with overcommit disallowed, the OOM killer is going to run
>>when my users try to run too big a job, so I would still like
>>the OOM killer to behave "well".
>
>
> Shouldn't - the process the user tries to run will not be started since
> it must reserve the space first. malloc will fail immediately, allowing the
> process to handle the even gracefully and exit.
I thought of that about five minutes after I hit 'send'.
I have a feeling that there might still be a few cases
not perfectly covered by the strict overcommit patch.
Say, memory allocations due to incoming network traffic.
I guess if memory runs out during incoming traffic, the kernel
should simply drop the traffic. Until all those situations
are nicely ironed out, there's still some chance the OOM killer
might run even on a strict overcommit system.
But enough talking; I need to go try it.
- Dan
--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
prev parent reply other threads:[~2003-03-03 16:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-28 1:21 Protecting processes from the OOM killer Dan Kegel
2003-02-28 13:40 ` Alan Cox
2003-02-28 14:19 ` Ville Herva
2003-02-28 15:37 ` Alan Cox
2003-02-28 16:08 ` Dan Kegel
2003-02-28 22:13 ` James Antill
2003-03-03 14:45 ` Jesse Pollard
2003-03-03 16:23 ` Alan Cox
2003-03-03 16:41 ` Dan Kegel [this message]
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=3E6385B0.1010706@kegel.com \
--to=dank@kegel.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=pollard@admin.navo.hpc.mil \
/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