Re: [GIT PULL] scheduler fixes

[Linus Torvalds]

On Mon, 18 May 2009, Ingo Molnar wrote:
> 
> Something like the patch below. It also fixes ->span[] which has a 
> similar problem.

Patch looks good to me.

> But ... i think this needs further clean-ups really. Either go fully 
> static, or go fully dynamic.

I do agree that it would probably be good to try to avoid this static 
allocation, and allocate these data structures dynamically. However, if we 
end up having to use two different allocators anyway (one for bootup, and 
one for regular uptimes), then I think that would be an overall loss 
(compared to just the simplicity of statically doing this in a couple of 
places), rather than an overall win.

> Would be nice if bootmem_alloc() was extended with such properties - 
> if SLAB is up (and bootmem is down) it would return 
> kmalloc(GFP_KERNEL) memory buffers.

I would rather say the other way around: no "bootmem_alloc()" at all, but 
just have a regular alloc() that ends up working like the "SMP 
alternatives" code, but instead of being about SMP, it would be about how 
early in the boot sequence it is.

That said, if there are just a couple of places like this that care, I 
don't think it's worth it. The static allocation isn't that horrible. I'd 
rather have a few ugly static allocations with comments about _why_ they 
look the way they do, than try to over-design things to look "clean".

Simplicity is a good thing - even if it can then end up meaning special 
cases like this.

That said, if we could move the kmalloc initialization up some more (and 
get at least the "boot node" data structures set up, and avoid any bootmem 
alloc issues _entirely_, then that would be good.

I hate that stupid bootmem allocator. I suspect we seriously over-use it, 
and that we _should_ be able to do the SL*B init earlier.

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