All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  parent reply	other threads:[~2007-10-18 22:19 UTC|newest]

Thread overview: 31+ 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:02   ` Andrew Morton
2007-10-26 21:05   ` Martin Bligh
2007-10-26 21:05     ` Martin Bligh
2007-10-26 21:11     ` Andrew Morton
2007-10-26 21:11       ` Andrew Morton
2007-10-26 21:35       ` Rik van Riel
2007-10-26 21:35         ` Rik van Riel
2007-10-26 21:59         ` Martin Bligh
2007-10-26 21:59           ` Martin Bligh
2007-10-26 22:30           ` Rik van Riel
2007-10-26 22:30             ` Rik van Riel
2007-10-28 21:16   ` Balbir Singh
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.