Re: OOM behavior in constrained memory situations

[Christoph Lameter <clameter@engr.sgi.com>]

On Tue, 7 Feb 2006, Andi Kleen wrote:

> On Tuesday 07 February 2006 02:55, Christoph Lameter wrote:
> > I just tried to oom a process that has restricted its mem allocation to 
> > node 0 using a memory policy. Instead of an OOM the system began to swap 
> > on node zero. The swapping is restricted to the zones passed to 
> > __alloc_pages. It was thus swapping node zero alone.
> 
> Thanks for doing that work. It's needed imho and was on my todo list.

This is talking not about the text above but about what comes later right? 
The OOM behavior for a constrained allocation with no swap?

> > +	gfp_t gfp_flags;	/* flags ORed into gfp_flags for each allocation */
> 
> I don't think it's a good idea to add it to the struct mempolicy. I've tried to
> make it as memory efficient as possibile and it would be a waste to add such
> a mostly unused field. Better to pass that information around in some other way.

Memory policies are rare and this would be insignificant on any NUMA 
system. 

> (in the worst case it could be a upper bit in policy, but I would prefer
> function arguments I think) 

An upper bit in policy would require special processing in hot code paths. 
The current implementation can simply OR in a value that is in a cacheline 
already in the data cache.

I'd rather keep it separate.

Function arguments? Add function pointer to mempolicy for allocation?

Then there is the other issue:

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? 

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.

-
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/