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

[Benjamin Herrenschmidt]

On Wed, 2009-06-17 at 09:01 -0700, Linus Torvalds wrote:
> 
> On Wed, 17 Jun 2009, Nick Piggin wrote:
> > 
> > In some cases perhaps it is difficult. In others it should be
> > pretty natural. Lots of memory allocating paths pass gfp
> > a long way down the stack.
> 
> I agree that some cases would be pretty natural. In fact, that's what we 
> started out doing. On the x86 side, we didn't have a lot of issues in 
> testing, and we fixed them up by using GFP_NOWAIT (see for example 
> cpupri_init() in kernel/sched_cpupri.c, or init_irq_default_affinity() in 
> kernel/irq/handle.c - both of which were fixed up in that phase).
> 
> Those paths, in fact, in general already had "bootmem" flags etc. And x86 
> doesn't need to initialize a lot of state at bootup. 
> 
> Then Ben happened, and crazy PPC ioremap crap. 

 :-)

Are you sure that none of the kmalloc's you turned into NOWAIT on x86
can be called after boot by things like CPU hotplug etc... ? In which
case, they just become much more prone to failure in the later case ...

How do you get away without ioremap in time_init(), init_IRQ() etc... ?
It's all IO ports and magic registers on x86 ?

So yeah, early ioremap is a problem, but it's also very useful to have
and will be hard to get rid of. I suspect most non-x86 platforms will
need something like that. Even if I end up managing to kill the callers
in setup_arch(), I will probably never get rid of ioremaps after the new
mm_init() and before interrupts are on.

There's a few other things in PPC land, like PCI stuffs, data structures
related to interrupt routing, etc... that can be allocated both at boot
and non boot, some of them we could probably push out to later but not
all and not without great care.

Cheers,
Ben.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/