From: Paul Jackson <pj@sgi.com>
To: Andi Kleen <ak@suse.de>
Cc: clameter@engr.sgi.com, akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: Terminate process that fails on a constrained allocation
Date: Wed, 8 Feb 2006 12:22:27 -0800 [thread overview]
Message-ID: <20060208122227.3379643e.pj@sgi.com> (raw)
In-Reply-To: <200602082005.12657.ak@suse.de>
If the oom killer is of any use on a numa system using set_mempolicy,
mbind and/or cpusets, then it would be of use in the bootcpuset -- that
cpuset which is often setup to hold the classic Unix daemons. I'm not
sure we want to do that.
If we changed the mm/oom_kill.c select_bad_process() constraint from
/* If p's nodes don't overlap ours, it won't help to kill p. */
if (!cpuset_excl_nodes_overlap(p))
continue;
which kills any task that has any overlap with nodes with the current task:
1) to the much tighter limit of only killing tasks that are on the same or
a subset of the same nodes, and
2) changed it to look at -both- the cpuset and MPOL_BIND constraints,
then oom killer would work in a bootcpuset rather as it does now on
simple UMA systems.
The new logic would be -- only kill tasks that are constrained to
the same or a subset of the same nodes as the current task.
With this, the problem you describe with the oom killer and a task that
has used mbind or cpuset to just allow a single node would be fixed --
only tasks constrained to just that node, no more, would be considered
for killing.
At the same time, a typical bootcpuset would have oom killer behaviour
resembling what people have become accustomed to.
If we are going to neuter or eliminate the oom killer, it seems like
we should do it across the board, not just on numa boxes using
some form of memory constraint (mempolicy or cpuset).
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
next prev parent reply other threads:[~2006-02-08 20:22 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-08 18:05 Terminate process that fails on a constrained allocation Christoph Lameter
2006-02-08 18:13 ` Andi Kleen
2006-02-08 18:34 ` Paul Jackson
2006-02-08 18:54 ` Christoph Lameter
2006-02-08 19:01 ` Andi Kleen
2006-02-08 19:15 ` Christoph Lameter
2006-02-08 18:33 ` Paul Jackson
2006-02-08 18:42 ` Christoph Lameter
2006-02-08 18:57 ` Paul Jackson
2006-02-08 19:02 ` Christoph Lameter
2006-02-08 19:05 ` Andi Kleen
2006-02-08 20:22 ` Paul Jackson [this message]
2006-02-08 20:36 ` Christoph Lameter
2006-02-08 20:55 ` Paul Jackson
2006-02-08 21:01 ` Andi Kleen
2006-02-08 21:03 ` Paul Jackson
2006-02-08 21:21 ` Andi Kleen
2006-02-08 21:39 ` Andrew Morton
2006-02-08 22:11 ` Christoph Lameter
2006-02-08 22:41 ` Andi Kleen
2006-02-08 23:29 ` Christoph Lameter
2006-02-08 23:35 ` Andrew Morton
2006-02-08 22:48 ` Christoph Lameter
2006-02-08 23:28 ` Christoph Lameter
2006-02-08 23:43 ` Andrew Morton
2006-02-08 23:54 ` Christoph Lameter
2006-02-08 23:57 ` Andi Kleen
-- strict thread matches above, loose matches on Subject: below --
2006-02-08 20:14 linux
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=20060208122227.3379643e.pj@sgi.com \
--to=pj@sgi.com \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=clameter@engr.sgi.com \
--cc=linux-kernel@vger.kernel.org \
/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