Re: [patch 3/4] oom: save zonelist pointer for oom killer calls

[Christoph Lameter <clameter@sgi.com>]

On Tue, 18 Sep 2007, David Rientjes wrote:

> On Tue, 18 Sep 2007, Christoph Lameter wrote:
> 
> > On Tue, 18 Sep 2007, David Rientjes wrote:
> > 
> > > +
> > > +	oom_zl = kzalloc(sizeof(*oom_zl), GFP_KERNEL);
> > > +	if (!oom_zl)
> > > +		goto out;
> > 
> > An allocation in the oom killer? This could in turn trigger more 
> > problems. Maybe its best to put a list head into the zone?
> > 
> 
> I thought about doing that as well as statically allocating
> 
> 	#define MAX_OOM_THREADS		4
> 	static struct zonelist *zonelists[MAX_OOM_THREADS];
> 
> and using semaphores.  But in my testing of this patchset and experience 
> in working with the watermarks used in __alloc_pages(), we should never 
> actually encounter a condition where we can't find
> sizeof(struct oom_zonelist) of memory.  That's on the order of how many 
> invocations of the OOM killer you have, but I don't actually think you'll 
> have many that have a completely exclusive set of zones in the zonelist.  
> Watermarks usually do the trick (and is the only reason TIF_MEMDIE works, 
> by the way).

You are playing with fire here. The slab queues *may* have enough memory 
to satisfy that requests but if not then we may recursively call into the 
page allocator to get a page/pages. Sounds dangerous to me.
 
> I'm not sure how embedding a list_head in struct zone would work even 
> though we're adding the premise that a single zone can only be in the OOM 
> killer once.  You'd have to recreate the zonelist by stringing together 
> these heads in the zone but the whole concept relies upon finding a 
> pointer to an already existing struct zonelist.  It works nicely as is 
> because the struct zonelist is persistent in __alloc_pages() so it is easy 
> to pass it to both zone_in_oom() and zonelist_clear_oom().

Then add a flag? Andrew and I talked about switching the all_reclaimable 
field to a bitmask? Do the conversion there and then we can add a OOM kill 
active state to each zone.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>