Re: Add SYSTEM_BOOTING_KMALLOC_AVAIL system_state

[Mike Kravetz <kravetz@us.ibm.com>]

On Tue, May 09, 2006 at 10:20:04AM -0700, Dave Hansen wrote:
> On Mon, 2006-05-08 at 22:49 -0700, Andrew Morton wrote:
> > 
> > How about some private boolean in slab.c, and some special allocation
> > function like
> > 
> > void __init *alloc_memory_early(size_t size, gfp_t gfp_flags)
> > {
> > 	if (slab_is_available)
> > 		return kmalloc(size, gfp_flags);
> > 	return alloc_bootmem(size);
> > }	
> 
> One issue with that approach is that you can't use it for larger
> allocations (which we have a lot of at boot-time).  Would it be OK to
> fall back to the raw page allocator for things where kmalloc() fails?
> Oh, and do we want to make it explicitly NUMA aware?

Well, I am making it NUMA aware as the first identified user of such
a routine does want to make node specific allocations.  I haven't thought
about the 'large' allocations.

Any thoughts about also including free_memory_early() routines?  It
seems like a good idea.  However,  I'm somewhat afraid of these gaining
widespread use and the potential mis-use.  Using free in the same routine
as the alloc (such as in error paths) is generally ok.  But, trying to
do a free at a later time requires the attention of the coder.  Just don't
want people to think these wrappers will be a substitute for that analysis.

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