All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Christoph Lameter <clameter@engr.sgi.com>
Cc: ak@suse.de, pj@sgi.com, linux-kernel@vger.kernel.org
Subject: Re: Terminate process that fails on a constrained allocation V3
Date: Thu, 9 Feb 2006 21:19:16 -0800	[thread overview]
Message-ID: <20060209211916.0b33db4b.akpm@osdl.org> (raw)
In-Reply-To: <Pine.LNX.4.62.0602091152300.9941@schroedinger.engr.sgi.com>

Christoph Lameter <clameter@engr.sgi.com> wrote:
>
> Some allocations are restricted to a limited set of nodes (due to memory
>  policies or cpuset constraints). If the page allocator is not able to find
>  enough memory then that does not mean that overall system memory is low.
> 
>  In particular going postal and more or less randomly shooting at processes
>  is not likely going to help the situation but may just lead to suicide (the
>  whole system coming down).
> 
>  It is better to signal to the process that no memory exists given the
>  constraints that the process (or the configuration of the process) has
>  placed on the allocation behavior. The process may be killed but then the
>  sysadmin or developer can investigate the situation. The solution is similar
>  to what we do when running out of hugepages.
> 
>  This patch adds a check before we kill processes. At that
>  point performance considerations do not matter much so we just scan the zonelist
>  and reconstruct a list of nodes. If the list of nodes does not contain all
>  online nodes then this is a constrained allocation and we should kill the
>  currnet process.

Looks sane, thanks.  I made constrained_alloc() inline, to give the
compiler the best-possible chance of eliminating the impossible-on-UMA
switch cases.


      parent reply	other threads:[~2006-02-10  5:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-09 19:53 Terminate process that fails on a constrained allocation V3 Christoph Lameter
2006-02-09 20:05 ` Andi Kleen
2006-02-09 20:12   ` Christoph Lameter
2006-02-09 20:14     ` Andi Kleen
2006-02-10  5:19 ` Andrew Morton [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=20060209211916.0b33db4b.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=ak@suse.de \
    --cc=clameter@engr.sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pj@sgi.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.