From: Andi Kleen <ak@suse.de>
To: Christoph Lameter <clameter@engr.sgi.com>
Cc: Paul Jackson <pj@sgi.com>, linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: OOM behavior in constrained memory situations
Date: Tue, 7 Feb 2006 18:58:12 +0100 [thread overview]
Message-ID: <200602071858.13002.ak@suse.de> (raw)
In-Reply-To: <Pine.LNX.4.62.0602070947100.24920@schroedinger.engr.sgi.com>
On Tuesday 07 February 2006 18:51, Christoph Lameter wrote:
> > I back then spent some time to make the data structure as small as possible
> > and I would hate to destroy it with such thoughtless changes.
>
> Well the ability to set bits for policy controlled allocations may come in
> handy if we want to support memory policy controlling some other aspect
> for page allocation.
Actually looking at it again "v" should be aligned to 4 bytes anyways, so
there is a unused 2 byte hole that you can use for this.
Still think the way of converting the policy is more elegant though.
> > when MPOL_BIND == node_online_map automatically revert to MPOL_PREFERED with empty mask.
> > Then on the allocation only set the gfp flag for MPOL_BIND
>
> That would work for MPOL_BIND. How about MPOL_INTERLEAVE with a restricted
> set of nodes? cpusets may cause any policy to have a restricted nodeset.
MPOL_INTERLEAVE isn't strict, so it can never cause OOMs unless the complete
system is out of memory. It just changes which node is tried first.
>
> > > Should the system swap if an MPOL_BIND request does not find enough
> > > memory? Maybe it would be good to not swap, rely on zone_reclaim only and
> > > fail if there is no local memory?
> >
> > Not sure. I guess it depends. Maybe it needs a nodeswappiness sysctl.
>
> Hmm.... Maybe make this a separate post?
Do you have enough new thoughts on it for one?
> > > We could change __GFP_NO_OOM_KILLER to __GFP_CONSTRAINED_ALLOC and then
> > > not invoke kswapd and neither the OOM killer on a constrained allocation.
> >
> > That could be a problem if one node is filled with dirty file cache pages,
> > no? There needs to be some action to free it. I had a few reports of this case.
> > It needs to make at least some effort to wait for these pages and push them out.
>
> zone_reclaim can be configured to write out dirty file cache pages during
> reclaim. So this could be addressed.
Would be good.
-Andi
next prev parent reply other threads:[~2006-02-07 18:02 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-06 20:59 OOM behavior in constrained memory situations Christoph Lameter
2006-02-06 21:10 ` Andrew Morton
2006-02-06 21:22 ` Andi Kleen
2006-02-06 22:16 ` Christoph Lameter
2006-02-06 22:25 ` Andi Kleen
2006-02-06 22:30 ` Andrew Morton
2006-02-07 0:03 ` Christoph Lameter
2006-02-09 23:08 ` David Gibson
2006-02-06 22:11 ` Christoph Lameter
2006-02-06 22:26 ` Andrew Morton
2006-02-06 22:59 ` Paul Jackson
2006-02-07 0:39 ` Christoph Lameter
2006-02-07 1:55 ` Christoph Lameter
2006-02-07 9:23 ` Andi Kleen
2006-02-07 17:29 ` Christoph Lameter
2006-02-07 17:45 ` Andi Kleen
2006-02-07 17:51 ` Christoph Lameter
2006-02-07 17:58 ` Andi Kleen [this message]
2006-02-07 18:10 ` Christoph Lameter
2006-02-07 18:19 ` Christoph Lameter
2006-02-07 18:31 ` Andi Kleen
2006-02-07 19:00 ` Christoph Lameter
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=200602071858.13002.ak@suse.de \
--to=ak@suse.de \
--cc=akpm@osdl.org \
--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.