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

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Tue, 2009-06-16 at 12:10 -0700, Linus Torvalds wrote:
> 
> All the recent init ordering changes should mean that the slab allocator 
> is available _much_ earlier - to the point that hopefully any code that 
> runs before slab is initialized should know very deep down that it's 
> special, and uses the bootmem allocator without doing any conditionals 
> what-so-ever.

I would normally agree ... but we still have some stuff in setup_arch()
that will need that :-( IE, we need to allow ioremap very early on
powerpc (and possibly various other archs that don't have magic PIO to
whack their chipset without the need for a mapping), so we have tricks
to allocate page tables using LMB, bootmem or slab depending on what's
available that still rely on slab_is_available().

Same goes with some PCI PHB related data structures that we are
allocating in setup_arch() as well, though that's something I do intend
to move to normal initcalls asap (there's a few skeletons hiding in some
corners there so it's not totally trivial).

In fact, I would love to be able to call the SLAB init myself from
somewhere in setup_arch() ... basically instead of init_bootmem() and be
done with it :-) I know it's a chicken-and-egg problem with allocating
the memmap etc... but heh. Which brings me back to my point, we do have
some kind of very very very early allocator on powerpc and sparc
(lib/lmb.), and I think x86 has one too (i820 or whatever it's called)
right ? Maybe we can wrap a common API on top of these things and avoid
bootmem alltogether ? Or that's just not realistic ?

> If that isn't true yet, then we should make it more true.

I agree.

> IOW, we should strive for not having any code that is at all confused 
> about whether it can do slab allocations or not.

Cheers,
Ben.