On Mon, 2006-06-05 at 15:40 +1000, Benjamin Herrenschmidt wrote:
> In various places, architectures need to request interrupts early during
> boot. Before slab is initialized typically. We used to have all sorts of
> arch hacks to do so, which ended up being turned into something like:
..../.... (skip workaround based on bootmem)
Hrm... I'm running into more problems with some of my powerpc irq
cleanups related to slab not being initialized.
Why do we do it so late ? I don't see any reason. A bunch of stuff like
init_IRQ(), time_init() etc...end up being called without a working slab
(not even GFP_ATOMIC). Damn, even console_init().
What are the fundamental reasons, if any, why we initialize the slab so
late ? Would it be possible to have the slab fallback to bootmem or some
crap like that early during boot (though that may be an issue for things
trying to free blocks) ?
For example, in my big irq rework for powerpc, I need to clean up the
virtual to physical irq mapping for which we are using a radix tree.
Right now, we kludge around in the pseries code to use that radix tree
late (that is to setup the cascaded interrupt from an arch_initcall),
but that's becoming a bigger issue as I'm trying to push some of that
stuff into a nice common remapping layer (we need that for cell too
among others). That's just an example of a low level utility (radix
trees) we can't use because it relies on the slab.
Another example is that things like init_IRQ(), time_init(),
console_init() etc.. need to be able to do ioremap. How many hacks are
archs cluttered with to be able to do ioremap before mem_init ? It
varies from hacks in pte_alloc_kernel() to use bootmem, to the use of
bolted hash entries on ppc64, etc....
Maybe we should have a look at pushing some things later into the boot
process that have no reason anymore to be done that early... And even if
not, a consistent memory allocator is something that I would really
consider as a very basic service that should be up before pretty much
everything else. It's not like the slab was relying on hardware to be up
or anything fancy... it doesn't even rely on vmalloc() to be available
nor the MMU in any consistent state outside of having the linear mapping
up (which I think all archs have at this point in time anyway).
I'm sure there is a subtle sneaky dependency, I would suspect something
to do with the scheduler and/or the cpumask/numa infos, whatever, but I
think we should really consider solving that.
Bootmem is a hack. It may be good enough for very-early-boot type
allocations, but them, I mean really really early (and even then, heh,
powerpc has it's own allocator that works even before bootmem is up).
Cheers,
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
