From: Rene Herman <rene.herman@keyaccess.nl>
To: Rik van Riel <riel@redhat.com>
Cc: Marcelo Tosatti <marcelo@kvack.org>,
linux-kernel@vger.kernel.org, drepper@redhat.com
Subject: Re: OOM notifications
Date: Fri, 19 Oct 2007 00:16:37 +0200 [thread overview]
Message-ID: <4717DB45.8000604@keyaccess.nl> (raw)
In-Reply-To: <4717D7B6.40102@keyaccess.nl>
On 10/19/2007 12:01 AM, Rene Herman wrote:
> On 10/18/2007 11:18 PM, Rik van Riel wrote:
>
>> On Thu, 18 Oct 2007 23:06:52 +0200
>> Rene Herman <rene.herman@keyaccess.nl> wrote:
>>
>>> They don't -- that's why I asked if you need both scenario's active
>>> at the same time. SIGDANGER would just be SIGPLEASEFREEALLYOUCAN with
>>> the operator deciding through setting the level at which point
>>> applications get it.
>>>
>>> Or put differently; what's the additional value of notifying an
>>> application that the system is about to go balistic when you've
>>> already asked it to free all it could earlier? SIGSEEDAMNITITOLDYOUSO?
>>
>> The first threshold - "we are about to swap" - means the application
>> frees memory that it can. Eg. free()d memory that glibc has not yet
>> given back to the kernel, or JVM running the garbage collector, or ...
>>
>> The second threshold - "we are out of memory" - means that the first
>> approach has failed and the system needs to do something else. On an
>> embedded system, I would expect some application to exit or maybe
>> restart itself.
>
> That first threshold sounds fine yes. To me, the second mostly sounds
> like a job for SIGTERM though.
>
> The OOM killer could after it selected the task for killing first try a
> TERM on it to give a chance to exit gracefully and only when that
> doesn't help make it eligible for killing on a second round through the
> badness calculation.
>
> You could moreover _never_ make a task eligible for killing before it
> received a SIGTERM, thereby guaranteeing that everyone got the SIGTERM
> before killing anything, and it seems SIGTERM would be a more focussed
> version of SIGDANGER2 then.
Well, no, that "guarantee" is fairly badly formulated but I mean "before
everyone got a SIGTERM" ofcourse. That is, first do the same selection as
now but don't send KILL but TERM and mark the task as having received a TERM
already and make it not eligible anymore. Only when there are no TERM
eligible tasks anymore, start sending KILL.
> Would at least forego any need for multiplexing the DANGER signal.
Rene.
next prev parent reply other threads:[~2007-10-18 22:19 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-18 20:25 OOM notifications Marcelo Tosatti
2007-10-18 20:38 ` Rene Herman
2007-10-18 20:52 ` Rik van Riel
2007-10-18 21:06 ` Rene Herman
2007-10-18 21:18 ` Rik van Riel
2007-10-18 22:01 ` Rene Herman
2007-10-18 22:10 ` Ulrich Drepper
2007-10-19 5:15 ` Chris Friesen
2007-10-19 10:17 ` Pavel Machek
2007-10-19 15:18 ` Samuel Tardieu
2007-10-19 16:58 ` Chris Friesen
2007-10-18 22:16 ` Rene Herman [this message]
-- strict thread matches above, loose matches on Subject: below --
2007-10-18 20:15 Marcelo Tosatti
2007-10-26 21:02 ` Andrew Morton
2007-10-26 21:05 ` Martin Bligh
2007-10-26 21:11 ` Andrew Morton
2007-10-26 21:35 ` Rik van Riel
2007-10-26 21:59 ` Martin Bligh
2007-10-26 22:30 ` Rik van Riel
2007-10-28 21:16 ` Balbir Singh
2007-10-30 14:57 ` Jan Kara
2007-10-30 15:23 ` Rik van Riel
2007-10-30 15:55 ` Jan Kara
2007-10-30 17:31 ` Rik van Riel
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=4717DB45.8000604@keyaccess.nl \
--to=rene.herman@keyaccess.nl \
--cc=drepper@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@kvack.org \
--cc=riel@redhat.com \
/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