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

True I could use these two spare bytes to store the 2 highest bytes of the 
GFP flags. But then I'd still have some more complicated bit arithmetic in the 
hot code paths of the page allocator to wedge these bits into the gfp 
flags.
 
> > > > 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?

Right now I think it could just work by simply not swapping for 
constrained allocations. Do an agressive zone_reclaim that writes out 
potentially dirty pages if needed. But that is a significant change of 
memory allocation behavior. Maybe that would need some kind of option 
during bind that would then set something in the gfp_flags that would then 
trigger the agressive zone_reclaim?

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