lkml.org 
[lkml]   [2006]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: OOM behavior in constrained memory situations
Date
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-02-07 19:05    [from the cache]
©2003-2011 Jasper Spaans