Re: OOM behavior in constrained memory situations

[Andi Kleen]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/