Re: [GIT PULL v2] Early SLAB fixes for 2.6.31

[Linus Torvalds <torvalds@linux-foundation.org>]

On Tue, 16 Jun 2009, Nick Piggin wrote:

> On Tue, Jun 16, 2009 at 07:31:38AM +1000, Benjamin Herrenschmidt wrote:
> > On Mon, 2009-06-15 at 13:23 +0200, Nick Piggin wrote:
> > > > I think the main problem isn't necessarily init code per se, but the
> > > > pile of -common- code that can be called both at init time and
> > > later.
> > > 
> > > Just seems bogus argument. Everwhere else that does this (ie.
> > > allocations that are called from multiple allocation contexts)
> > > passes correct gfp flags down.
> > 
> > So you say we should create new variants of all these APIs that take gfp
> > flags as arguments just because they might be called early during boot :
> 
> No, just create the ones that actually are called in early boot.

No.

Nick, I don't think you've follow the problems.

The thing is, we do end up wanting to do a lot of allocations, and it's 
not even very "early" - we've already initialized all the allocators. It's 
just that WE HAVE NOT ENABLED INTERRUPTS YET!

So the "hack" is to let everybody act as if everything is normal. Which it 
pretty much is. Just use kmalloc/kfree etc, and use _all_ the regular 
functions. Setting up the core layers so that we _can_ enable interrupts 
involves quite a lot of random crud, they should be able to use regular 
code.

And the hack is there because we really are in a magic stage. The memory 
management works, but it just can't do certain things yet. It's not the 
callers that need to be changed, because the callers are usually regular 
routines that work perfectly normally long after boot, and having to add a 
magic "I'm now doign this during early boot" argument to the whole stack 
is just _stupid_, when the stack itself doesn't actually care - only the 
allocators do.

			Linus