Re: [RFC][PATCH] request_irq(...,SA_BOOTMEM);

[Andrew Morton <akpm@osdl.org>]

On Mon, 05 Jun 2006 17:08:29 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> 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 ?

I suspect because it's been like that since for ever, and any time we touch
anything in there, bad things happen.

> ...
>
> 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.

I don't immediately see anything in there which would prevent us from
running these:

	vfs_caches_init_early();
	cpuset_init_early();
	mem_init();
	kmem_cache_init();
	setup_per_cpu_pageset();

just after sort_main_extable().

But things will explode ;)

I suggest you run up a patch, test it on whatever machines you have, send
it over and I'll do the same.  But please make sure it has a config option
to restore the old sequence for now.  a) So people can work out that it was
this patch which broke things and b) so it doesn't adversely affect testing
of other things too much.

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